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CUVÂNT ÎNAINTE 


Promovarea masivă a calculatoarelor în domeniul 
conducerii, supravegherii și investigării de procese, cu tot ce ea 
a implicat, a fost posibilă doar prin utilizarea unor tehnici şi 
mijloace de programare speciale, capabile să asigure tratarea în 
timp real, în regim concurent, a informaţiilor. 


Aceste tehnici şi mijloace au o relativ slabă reprezentare 
bibliografică, în literatura română putându-se vorbi, referitor la 
ele, chiar despre un cvasivid. 


În acest context, lucrarea “PROGRAMARE 
CONCURENTA. MECANISME SUPORT ORIENTATE TIMP 
REAL” vine în întâmpinarea persoanelor interesate să-şi 
însușească principiile care stau la baza tehnicilor și 
mijloacelor de programare invocate. Sunt avuţi în vedere atât 
studenții -în primul rând cei de la specializările: calculatoare, 
automatică şi informatică industrială, electronică aplicată, 
telecomunicații, informatică, dar nu numai-, cât şi inginerii. 
De altfel, în situația în care informatizarea este cuvântul de 
ordine cel mai chemat să-şi lase amprenta asupra tuturor 
segmentelor societăţii româneşti, pentru a-i oferi acesteia 
o şansă de apropiere de nivelele la care s-a ajuns în ţările 
avansate, tot mai mulți specialişti, cu diverse formații de bază 
-profesori, medici, economişti, etc.- sunt preocupaţi de 
deprinderea abilității de a folosi calculatorul în mod cât mai 
judicios; iar aceia dintre ei care, în acest sens, doresc să 
pătrundă inclusiv în  “background”-ul programării 
concurente, găsesc în lucrarea noastră informații generate şi 
prezentate astfel încât să le poată da satisfacţie în demersul 
lor. Întru susținerea acestei afirmaţii, menționăm următoarele: 
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CUVÂNT ÎNAINTE 


CAP. 1. CONSIDERAȚII INTRODUCTIVE 


o pentru fiecare din conceptele teoretice atacate, lucrarea 
oferă o soluţie de implementare, cu o pronunțată tentă 
didacticistă 

e fiecare din principalele subcapitole ale lucrării este 
urmat de un set de întrebări, cu ajutorul cărora cititorii 
îşi pot verifica cunoştinţele dobândite, pe măsură ce 
avansează în procesul de studiu 

o după fiecare capitol, se oferă un rezumat al capitolului, 
iar apoi un set de întrebări vizând tot ce este mai 
important de reținut din substanța capitolului respectiv. 


Lucrarea conţine opt capitole: 


în 


Capitolul 1 îşi propune, mai întâi, să scoată în evidenţă în 
ce tip de aplicaţii este oportună programarea concurentă şi 
care sunt modalităţile prin care ea poate fi asigurată, iar apoi, 
să clarifice principalele noţiuni ale domeniului. 


Capitolul 2 este dedicat definirii stărilor taskurilor şi 
prezentării posibilităților de evoluție a taskurilor în spațiul 
stărilor. 


Capitolul 3 tratează problematica comutării taskurilor. 
Capitolul 4 este axat pe dispecerizarea taskurilor. 


Capitolul 5 atacă problema stabilirii perioadei cu care se 
realizează comutarea taskurilor. 


Capitolul 6 abordează problema conflictelor pe care le 
poate ocaziona procesarea concurentă, punând accentul pe 
principalele soluţii de rezolvare a lor. 


Capitolul 7 are ca tematică problematica sincronizării 
taskurilor. i 


Capitolul 8 se referă la problema comunicării între taskuri. 


Sperând că lucrarea noastră va avea ecouri pozitive, îi 
asigurăm pe cititori de sentimentele noastre cele mai alese la 


adresa lor. 


Autorul 


1 
CONSIDERAŢII INTRODUCTIVE 


Vecinătatea temporală a momentului curent se caracterizează, 
în mod distinctiv, prin automatizarea masivă a mijloacelor tehnice 
şi a activităților umane, mai ales productive şi prestatoare de 
servicii. 


Acest proces se realizează, practic unanim, cu ajutorul 
echipamentelor electronice de prelucrare a informaţiilor. De 
aceea, pentru desemnarea lui, se foloseşte tot mai frecvent 
termenul "informatizare". 


Informatizarea mijloacelor tehnice și chiar a celor două 
categorii de activități menţionate presupune crearea unor sisteme 
informatice specifice, denumite sisteme informatice în timp real. 


Un sistem informatic în timp real este un sistem de tratare de 
informaţii care are ca misiune controlul "pe viu” al unei aplicaţii, 
cu respectarea constrângerilor temporale pe care ea le 
impune [20]. 


Această misiune de control este realizată printr-un ansamblu de 
acțiuni individualizabile din punct de vedere funcțional şi 
temporal, cu un anumit grad de autonomie unele în raport cu 
altele în ceea ce privește derularea lor, având, eventual, relații 
între ele [12]. 


Sistemele informatice în timp real fac parte din categoria 
sistemelor "on-line", caracterizate prin faptul că preiau 
informațiile de intrare direct de la locul în care acestea se 
generează și transmit informațiile de ieşire direct la locul în care 
ele îşi ating finalitatea. 


l 
| 
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Preluarea în sistem a informaţiilor de intrare, respectiv 
disponibilizarea informaţiilor de ieşire se asigură cu ajutorul unor 
terminale, ce pot fi de două tipuri: 

- mijlocitor între operatorul uman şi sistem; 
- mijlocitor între sistem şi aplicația controlată. 


Din prima categorie, fac parte echipamentele periferice de 
introducere / extragere universale sau specializate, cum sunt: 
tastaturile, mmouse-ii, afişajele (cinescopice, cu cristale lichide, cu 
plasmă, cu LED-uri, etc.), imprimantele, ploterele ş.a.m.d. 


A doua categorie cuprinde traductoarele pentru măsurarea 
mărimilor caracteristice aplicaţiei, respectiv elementele de 
execuţie care asigură intervenția asupra aplicației. 


Dacă un sistem informatic "on-line" preia datele de. intrare 
suficient de prompt şi de rapid pentru a se putea garanta că nici o 
evoluţie semnificativă nu este scăpată şi efectuează tratarea lor şi 
disponibilizarea informațiilor de ieşire suficient de prompt și de 
rapid pentru ca acestea să fie oportune și eficiente, atunci acel 
sistem devine sistem informatic în timp real. 


Sintetizând cele de până aici, putem, aşadar, formula 
următoarea definiție pentru un sistem informatic în timp real: 


Se numeşte sistem informatic în timp real un sistem de tratare 
de informaţii "on-line", care are ca misiune controlul "pe viu” al 
unei aplicaţii, cu respectarea constrângerilor temporale pe care 
ea le impune, adică, cu asigurarea: 


e preluării datelor de intrare cu suficientă promptitudine şi 
rapiditate pentru a fi un lucru garantat că nici o evoluţie 
semnificativă nu este scăpată 

e tratării datelor de intrare şi a informaţiilor anterioare despre 
aplicaţie cu suficientă promptitudine şi rapiditate 

e disponibilizării informațiilor de ieşire cu suficientă 
promptitudine şi rapiditate pentru ca acestea să fie oportune şi 
eficiente 
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Transpare, din cele de mai sus, faptul că cerința specifică ce se 
impune unui sistem informatic în timp real este promptitudinea în 
generarea de răspunsuri la informaţiile de intrare. 


Aprecierea cantitativă a gradului în care un sistem informatic 
satisface această cerință se realizează printr-un indicator numit 
timp de răspuns, reprezentând intervalul temporal dintre 
momentul producerii unui eveniment în cadrul aplicației şi 
momentul în care sistemul îşi exteriorizează răspunsul la 
evenimentul respectiv. 


În principiu, sistemele informatice în timp real ar putea fi 
elaborate într-o abordare obișnuită, secvenţială, prin utilizarea 
unui limbaj de programare de nivel înalt sau de asamblare și a 
capabilității de întrerupere cu care sunt înzestrate calculatoarele. 
O asemenea abordare ar fi, însă, în multe cazuri, extrem de 
greoaie şi de ineficientă, conducând chiar la imposibilitatea 
satisfacerii cerințelor unora dintre aplicaţii. De aceea, pentru 
dezvoltarea sistemelor informatice în timp real, s-a apelat la așa 
numita programare concurentă, prin care se face posibilă 
modularizarea funcţională a programelor și avansarea în paralel a 
activităților cuprinse în diverse module, oferindu-se, pentru 
aceasta, facilități adecvate de exploatare în comun a unor resurse 
ale sistemului, de sincronizare şi schimb de date între diversele 
module [18]. 


Programarea concurentă se poate asigura, în principiu, pe două 
căi. 


Prima dintre ele are la bază utilizarea unor limbaje speciale, 
numite limbaje de programare concurentă, cum sunt: 
MODULA-2 şi ADA. Acestea permit dezvoltarea sistemelor 
informatice în timp real cu constrângeri temporale relativ slabe, 
fiind adecvate pentru aplicaţiile din sfera prestărilor de servicii 
(tranzacţii bancare, rezervări de locuri etc.). Nu pot asigura, însă, 
de cele mai multe ori, satisfacerea cerințelor privind timpul de 
răspuns, impuse de aplicaţiile din sfera automatizării mijloacelor 
tehnice şi a producției, aplicații în care sistemul informatic este 
implicat, de exemplu, în controlul unor procese de natură electrică 
sau mecanică, respectiv în controlul unor procese tehnologice 
deosebit de complexe, cu o dinamică ridicată [6]. 
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A doua cale pe care se asigură programarea concurentă are la 
bază utilizarea limbajelor de asamblare sau a limbajelor de nivel 
înalt cu eficiență ridicată în ceea ce priveşte codul executabil pe 
care îl generează (de exemplu: limbajul C), exclusiv sau 
combinat, şi a unui instrument "software" cu capabilități de 
asigurare a gestionării în condiţii de concurență a resurselor 
sistemului, a sincronizării și a schimbului de date între modulele 
de program apte să-și avanseze activitățile în paralel. Acest 
instrument "sofiware" - nu este altceva decât un nucleu 
particular de sistem de operare şi poartă denumirea de executiv de 


timp real [5]. 


A doua cale este mai performantă decât prima în ceea ce 
priveşte timpii de răspuns şi dimensiunea codului executabil la 
care se poate ajunge. Explicația consistă în faptul că prima cale 
este mai bogată în facilități de asistare a dezvoltării programelor, 
dispunând, de exemplu, de o mai mare capacitate de detecție şi 
semnalare a unor situaţii anormale ce se pot ivi în timpul rulării, 
iar- pentru aceasta, mecanismele sale intime, inserate în 
programele de aplicaţii, sunt mai sofisticate şi, implicit, mai lungi 
în cod şi mai mari consumatori de timp decât cele înglobate în 
executivele de timp real specifice celei de-a doua căi [8]. 


Privitor la categoriile de aplicaţii la care s-a făcut 
referire mai sus -aplicațiile de informatizare a mijloacelor 
tehnice, a activităţilor productive şi a activităților din sfera 
prestărilor de servicii-, se impun câteva precizări. 


Informatizarea mijloacelor tehnice şi a activităţilor productive 
presupune, în esenţă, culegerea unor date din instalațiile tehnice 
în cauză şi din mediul lor ambiant, prelucrarea acestora în 
conformitate cu strategiile de control stabilite şi generarea de 
comenzi către elementele de execuţie, în vederea asigurării 
dezideratelor propuse [6]. 


Informatizarea activităților din sfera prestărilor de servicii 
presupune, în principiu, consultarea şi actualizarea unor baze de 
date de către mai mulţi utilizatori, care pot interveni simultan, 
fiecare de la câte un terminal dintre mai multe existente în 
sistem [6]. 
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Chiar şi din aceste sumare precizări, rezultă că problematica 
sistemelor informatice în timp real aferentă celor două categorii 
de aplicaţii diferă considerabil, nefiind, totuşi, de neglijat 
aspectele lor comune. Pentru detaliere, să considerăm, pe rând, 
câte un exponent generic al celor două categorii de sisteme 
informatice în timp real. 


În figura 1_1, se prezintă schematic un sistem în timp real 
pentru conducerea unui proces tehnic sau tehnologic. 


Sistemul informatic este conectat direct la procesul condus, 
prin intermediul  convertoarelor analog-numerice, CAN, și al 
porturilor de intrări logice, PIL, respectiv prin intermediul 
convertoarelor numeric-analogice, CNA, şi al porturilor de ieșiri 
logice, PEL. 


] Informaţiile despre proces sunt preluate de sistem prin 
| explorare ciclică -cu o periodicitate determinată de dinamica 
| procesului-, a traductoarelor, T, şi a sesizoarelor de stări 
| bivalente, S. 


Aceste. informații sunt supuse unor verificări şi prelucrări 
preliminare în cadrul modulului 1, iar apoi interpretate şi 
introduse în calcule, în cadrul modulului 2, conform unor 
stratepii de conducere prestabilite. În__urma_ acestor calcule, 
se determină mărimile de comandă, care se emit periodic, prin 
intermediul modulului 3, spre elementele de execuţie, E. 


Periodicitatea conectării sistemului informatic la proces, în 
ambele sensuri, este esenţială, ea stând la baza modelelor 
matematice corespunzătore strategiei de conducere implementată 
prin program. Asigurarea acestei periodicități este în sarcina aşa- 
numitului ceas de timp real, 4. Acesta reprezintă o resursă 
materială, implementată cu circuite de tip numărător 
programabil, având capabilitatea de a emite cereri de întrerupere 
la scurgerea unor intervale de timp prestabilite şi de a furniza, la 
cerere, informaţii privind momentul curent. 
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Fig. 1_1. Schema generică a unui sistem în timp real 
| pentru conducerea unui proces tehnic sau tehnologic. 
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Suplimentar față de sarcinile menționate, sistemul informatic 
asigură crearea şi întreținerea unei baze de date despre proces, 5, 
cu ajutorul modulului 6. Această bază de date, constituită, de 
regulā, din informații sintetice, este consultată de modulul care 
implementează strategia de conducere, 2, putând fi folosită, de 
exemplu, pentru actualizarea acestei strategii, pe baza analizei 
rezultatelor obținute prin aplicarea ei. De asemenea, baza de date 
este folosită de către modulul 7, pentru generarea unor rapoarte 
oferite operatorului prin afişajul consolei, 8, sau cu ajutorul unei 
imprimante, 9. 


După cum rezultă din figură, modulul 7 are, de asemenea, rolul 
de a genera alarme în cazul în care apar anomalii. 


Din această prezentare succintă a structurii şi funcţiilor unui 
sistem informatic în timp real pentru conducerea unui proces 
tehnic sau tehnologic, se poate concluziona că el necesită resurse 
materiale specifice: interfețe de proces pentru achiziţia și 
generarea de mărimi analogice şi logice, ceas de timp real versatil 
şi sistem de întreruperi puternic. 


În ceea ce priveşte programul, se remarcă structurarea sa în 
cinci module: 


1). modulul de culegere a datelor 

2). modulul de prelucrări conforme strategiei de conducere 

3). modulul de emitere a comenzilor 

4). modulul de actualizare a bazei de date 

5). modulul de deservire a operatorului, 
rapoartelor şi semnalizare a anomaliilor 


generare a 


Această structurare are doar o valabilitate generică. În practică, 
programele se modularizează mai nuanţat, astfel încât fiecare 
modul reuneşte acțiuni conjugate, ale căror premize de derulare 
necesitate din exteriorul ansamblului pe care ele îl constituie sunt 
aceleaşi, şi care se pot desfășura, cel puţin în parte, în paralel cu 
altele, constituite în alte module. 


Un modul de program constituit conform celor de mai sus 
poartă denumirea de "ask", 
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Dar termenul "ask" se foloseşte şi pentru a desemna un 
program, în ansamblul său, atunci când programul are 
proprietatea că o sesiune de rulare a sa se poate desfăşura în 
paralel sau cvasiparalel cu sesiunile de rulare ale altor programe 
sau chiar cu alte sesiuni de rulare ale lui însuşi. 


Aşadar, vom apela cu numele de "task" modulele de program 
şi programele ce reunesc activități autonome sau independente şi 
au proprietatea că o sesiune de rulare a lor se poate desfăşura în 
paralel sau cvasiparalel cu sesiunile de rulare ale altor module sau 
programe sau chiar cu alte sesiuni de rulare ale lor înseși. 


Taskurile ce reprezintă module ale unui program se mai 
numesc "/kread-uri" sau "fire de execuție”. 


Taskurile ce reprezintă programe de sine stătătoare se mai 
numesc "procese". 


Procesarea în paralel sau cvasiparalel a mai multor taskuri se 
numește "multitasking". 


Procesarea în paralel sau cvasiparalel a mai multor taskuri cu 
statut de rhread-uri se numeşte "multithreading" sau, de 


asemenea, "multitasking cooperativ”. 


Procesarea în paralel sau cvasiparalel a mai multor taskuri cu 
statut de procese se numeşte "multiprocessing" sau, de asemenea, 
"multitasking non-cooperativ". 


Procesarea în paralel sau cvasiparalel a mai multor taskuri cu 
statut de procese, dintre care, cel puţin unele, consistă într-un 
număr multiplu de fhread-uri, se numeşte "multiprocessing cu 
multithreading". 


Menţionăm că termenii "task" şi "multitasking" sunt adesea 
folosiți cu sensul de "proces" şi "multiprocessing", ceea ce, 
inevitabil, implică şi ajungerea la sintagma "multitasking cu 
multithreading", în contexte în care, de fapt, este vorba de 
“multiprocessing cu multithreading". 
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Când multitasking-ul intervine în contextul timpului real, se 
vorbeşte despre "sisteme informatice în timp real cu 
multitasking". 


De regulă, sistemele informatice în timp real cu multitasking 
instanțiază multitasking-ul cooperativ (altfel spus: sunt, de fapt, 
"sisteme informatice în timp real cu multithreading"). Se poate 
înţelege lesne că acesta este şi cazul sistemului informatic în timp 
real de conducere a unui proces tehnic sau tehnologic considerat 
de noi mai sus. 


În multitasking-ul cooperativ, pentru atingerea obiectivelor 
impuse ansamblului lor, taskurile interacționează unele cu 
altele, sincronizându-şi acţiunile şi transmițându-și, reciproc, 
diverse date. Şi în multitasking-ul non-cooperativ există o 
interacţiune între taskuri, anumite sincronizări între acțiunile lor 
fiind inevitabil necesare, dar asta numai în legătură cu utilizarea 
de către ele în comun a unora dintre resursele sistemului. 


Programarea multitasking asigură o eficiență ridicată a 
activităţii de concepție și implementare a sistemelor informatice, 
facilitând, totodată, obţinerea unor performanţe îmbunătăţite în 
ceca ce priveşte timpii de răspuns. Într-un sistem cu 
multitasking, la producerea unui eveniment extern, taskul aflat în 
rulare poate ceda rapid locul altui task, impus de evenimentul 
respectiv. De exemplu, generarea de către ceasul de timp real a 
unei întreruperi ce marchează un moment de eşantionare poate 
determina abandonarea temporară a rulării taskului curent, care ar 
putea fi taskul de generare rapoarte, şi lansarea în execuție a 
taskului de culegere a datelor din proces. Dacă sistemul posedă un 
singur convertor analog-numeric, asigurând prin multiplexare 
achiziția mai multor mărimi, atunci din momentul în care se 
dispune de una dintre acestea până în momentul disponibilizări 
succesoarei ei, intervine un timp în care taskul de culegere a 
datelor nu are ce face. Drept urmare, el poate ieşi din rulare 
pentru a permite, de exemplu, reluarea și avansarea taskului 
întrerupt mai devreme. 


17 poa FOUTEN NICA > 


G.G ORAS 7. TIM 


B- rr BISLIOTEC 


sa 


CAP. 1. CONSIDERAȚII INTRODUCTIVE 


18 19 


În general, lansarea în rulare a taskurilor se poate provoca în 
momente de timp fixate aprioric ("fime-driven”) sau în momente 
imprevizibile ("event-driven"), legate de anumite evenimente 


[19]. 


În figura 1_2, este schițat un sistem în timp real pentru 
exploatarea concurentă a unei baze de date [6]. 


Un astfel de sistem implică asigurarea utilizării simultane a 
unui număr de terminale de tip echipament periferic de 
introducere / extragere, de la care diverşi utilizatori intervin 
asupra bazei de date, pentru a o consulta sau actualiza. În sistemul 
considerat, se presupune că intervenţiile utilizatorilor se exprimă 
prin așa numitele "/ranzacții”, cărora le corespund anumite 
operații asupra bazei de date. Sistemului i se pretinde să fie 
capabil să reacționeze suficient de prompt față de oricare dintre 
utilizatori, astfel încât fiecare dintre aceștia să fie deservit ca și 
cum ar fi unicul. Evident, aceasta în condiţiile în care resursele de 
care sistemul dispune sunt exploatate în comun, în regim 
concurențial, de către toţi utilizatorii. 
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A Tratare | 
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1 f Monitor bază Bază 
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terminale | ”]tranzacții 

T m=6+n-l 

i e Tratare ->l 
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a 

1 : wrih a A 

Fig. 1_2. Schema generică a unui sistem în timp real 

n pentru exploatarea concurentă a unei baze de date. 
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CAP. 1. CONSIDERAȚII INTRODUCTIVE 


REZUMAT 


Se numeşte: informatizare: automatizarea. cu :ajutorul 
calculatorului şi-sau- asistarea de către calculator a;mijloacelor 
tehnice şi â-activităților. umane: 


Se:numeşte sistem informatic "on-line" un. sistem. de tratare 
de informatii care preia informaţiile de intrare direct de la locul 
în cure acestea se generează. şi. transmite. informatiile de ieşire 
direct la locul în care ele îşi ating finalitatea. 


Se numeşte: sistem informatic în timp Yeal un sistem de tratare 
de informaţii "on-line", care are ca misiune controlul "pe viu" al 
unei aplicaţii, cui... respectarea. constrângerilor. temporale “ipe 
care. ea le impune, adică, cu asigurarea: 


e preluării datelor: de. intrare cu: suficientă promptitudine: şi 
rapiditate. pentru -a' fi. nn: lucru garantat că nici o evoluţie 
semnificativă nu este scăpată: A Eta 

e: trairi datelor de intraře:şia informațiilor anterioare despre 
aplicaţie cu suficientă promptitudine şi rapiditate : 

e. 'disponibilizăiii -- informaţiilor. de: ieşire... cu. suficientă 
promptitudine şi rapiditate pentru ca acestea să. ie oporhine 
şi eficiente 


Se numeşte. tin 
momentul producerii unui eveniment. în cadrul aplicației şi 
momentul: fn- care: sistemul îşi. -exteriorizează răspunsul... la 
evenimentul respectiv. 


Se numeşte taskun- modul: de progranm sau un progran: ce 
reuneşte activități autonome saw independente şi are proprietatea 
că:o sesiune de. rulare a sa se poate 'desfăşura în paralel: său 
cvasiparalel. cu. -sesiunile de: rulare: ale altor module -sau 
programe sau chiai: cu alte sesiuni derulare ale: lui însuşi. 


Se numeşte thread sau fir. de execuție un task cu. statul de 
inochil de program. 
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Se numeşte: proces „un "task: Cu statut. de. progratn de “sine 
75 pe 
stătĂtOY. 


Se numeşte “multitasking” procesarea. În paralel. sau 
cvasipăralel a mai multor taskuri: 


Se miiheşte "multithreading" sau, de asemenea, "multitasking 
cooperati»" procesarea, în paralel sau cvasiparalel a mai multor 
făskui-i cu statul de thread-uri. 


Se numeşte "multiprocessing! sau, de. asemenea, 
"multitasking  non-cooperativ" procesarea. în. paralel -sau 
cvasiparalel a mai multor taskuri cu statut de procese. 


Se numeşte "multiprocessing cu multithreading" procesarea 
în paralel sau cvasiparalel. a mai multor tăskuri: cu Statut. de 
procese, dinte 'care,cel puţin unele, consistă într-un număr 
multipli de (ital | 


ose mimeşte executiv. de timp real un instrument "software" 
muelen de sistem de] operare capabil si să asigure rularea în paralel 
sau: cvasiparălel ta unui număr: de tashuri, printr-un. Sel de 
mecanisme ce rezolvă şi-sau făcilitează: 


o` gestionarea de resurse în condiţii de concurență 

o: sincronizarea taslairilor unele ‘cu altele şi: cu evenimente 
externe: 

o comunicarea sau: schimbul: de date dintre taskuri. 


Sistemele informatice. în timp: real consistă în programe 
concurente a căror. dezvoltare:se face: 
Iautilizând limbaje: de> programare concurentă 
(MODULA-2, ADA, eic.) 

său, mai:ales: 

2 utilizând limbaje de asamblare sau linbaje de nivel înalt 
tueficienţă ridicată în ceea ce priveşte codul executabil 
pe care îl generează (de exemplu: limbajul C), exclusiv 
sau combinat, şi un executiv de timp real: 
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ÎNTREBĂRI: 


D. 
2). 
3). 
4). 
5). 
6). 
7). 
8). 
9), 

10). 

11). 


12), 
13). 


14). 


Ce se înțelege prin informatizare? 

Ce este un sisteni informatic "on-line! ? 

Ce este un sistem informatic în timp real? 

Ce este timpul de răspuns? 

Ce este un task? 

Ce este un thread? 

Ce'este un proces? 

Ce.se este multitasking-ul? 

Ce se este multithreading-ul? 

Ce se este multiprocessing-ul? 

Ce este multiprocessing-ul cu multithreading? 

Ce este un executiv de timp real? 

În ce tip:de programe consistă sistemele informatice 
în timp real? 

În ce mod pot fi dezvoltate BP ogr amele concur ente? 
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2 
STĂRILE TASKURILOR 
ȘI EVOLUȚIA ÎN SPAȚIUL 
STĂRILOR 


2.1. Stările taskurilor 


Starea necrear 


Un task în starea necreat este un task necunoscut de 
executiv. 


Într-un sistem ce dispune de memorii externe, taskurile în 
starea necreat nu sunt încărcate în memorie şi nu au alocate 
zone de cod, date şi stivă. 


Într-un sistem fără memorii externe, taskurile în starea 
necreat au codul încărcat în memorie, dispun, eventual (adică: 
nu obligatoriu!), de zonă de date, dar nu dispun de zonă de 
stivă. Nimic nu împiedică preferarea acestei situaţii şi pentru 
cazul sistemelor cu memorii externe. 


Singura tranziţie posibilă din starea necrear este către starea 
creat. 


Starea creat 


Un task în starea creat este un task cunoscut de executiv, 
având atribuit un identificator şi alocată memorie atât pentru 
cod, cât şi pentru date şi stivă. 


Tranziţiile posibile din starea creat sunt către stările gata, 
respectiv recreat. 
23 
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CAP. 2. STĂRILE TASKURILOR ... 


Starea gata 


Un task în starea gata este un task apt de rulare, care nu 
rulează efectiv doar pentru că procesorul este, pentru momeni, 


ocupat de un alt task.. 


Evident, dintre taskurile aflate la un moment în starea gala, 
unele nici nu şi-au început încă rularea, neajungând deloc la 
procesor, în timp ce altele au rulat deja, nemairulând şi în 
momentul respectiv doar pentru că le lipseşte procesorul, şi nu 
din alte motive. Menţionăm că unii autori cataloghează 
taskurile gata din această a doua categorie drept taskuri în 
execuţie logică, dedicându-le inclusiv o stare de sine stătătoare, 
numită în execuție logică [20]. 


Tranziţiile normale din starea gata sunt către una din 
stările în execuţie, respectiv în aşteptare. Există, însă, şi 
sisteme care admit tranziţia de la starea gata către starea creat 
sau chiar o tranziţie de la starea gata către starea necreat. 
Precizăm că acestea trebuie executate cu o deosebită atenție, 
pentru a nu lăsa sistemul multitasking în situaţii improprii (de 
exemplu: cu o resursă figurând ocupată de un task devenit 


necreat, €tc.). 


Starea în execuție 


Un task în starea în execuţie este un task care rulează efectiv, 
având la dispoziţie, pentru moment, procesorul. 


Când un task iese din execuţie prin pierderea controlului 
asupra procesorului, rămânând în execuție logică (adică: 
trecând în starea gata) sau blocându-se, întregul său context de 
rulare este salvat, pentru a putea fi refăcut, în vederea 
posibilitării continuării rulării sale. 


Tranziţiile normale din starea în execuție sunt către una din 
stările gata, respectiv în aşteptare. Există, însă, şi sisteme care 
admit tranziţia de la starea în execuție către starea creat sau 
chiar o tranziție de la starea în execuţie către starea necrear. 
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Precizăm că acestea trebuie executate cu o deosebită atenţie, 
pentru a nu lăsa sistemul multitasking în situaţii improprii (de 
exemplu: cu o resursă figurând ocupată de un task devenit 
necreat, etc.). 


Starea în aşteptare 


Un task în starea în aşteptare este un task care a fost în 
execuţie, dar a devenit inapt de rulare, înainte de a se încheia, 
prin survenirea în cadrul lui a unei condiţii de blocare. Cauzele 
blocării unui task sunt multiple: aşteptarea unui mesaj, 
aşteptarea unui eveniment, aşteptarea disponibilității unei 
resurse critice, aşteptarea expirării unei perioade de adormire, 
etc. 


In momentul blocării unui task, întreg contextul său de 
rulare este salvat, pentru a putea fi refăcut, cu ocazia relansării 
sale fizice în execuţie, ca urmare a dispariției condiţiei de 
blocare [20]. 


Tranziţia normală din starea în așteptare este către starea 
gata. Există, însă, şi sisteme care admit tranziţia de la starea în 
aşteptare către starea creat sau chiar o tranziţie de la starea în 
aşteptare către starea necreat. Precizăm că acestea trebuie 
executate cu o deosebită atenţie, pentru a nu lăsa sistemul 
multitasking în situaţii improprii (de exemplu: cu o resursă 
figurând ocupată de un task devenit necrear, etc.), 


Starea în aşteptare este referită frecvent şi prin sintagma 
"starea blocat". 


2.2. Evoluţia taskurilor în spaţiul 
stărilor 


Tranziţia necreat — creat 


Această tranziție se realizează printr-o directivă a 
executivului, denumită creare. 
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Crearea unui task consistă în a-i atribui un identificator şi 
a-i aloca memorie pentru cod, date și stivă -dacă nu cumva le 
are deja alocate din starea necreat-, respectiv în a-i comunica 
executivului adresa de start pe care respectivul task o are și 
prioritatea sa -evident: asta doar în sistemele cu taskuri 
prioritizate-. 


Crearea unui task se poate face fie în timpul rulării unei 
aplicaţii, fie la compilare. Prima alternativă, permițând crearea 
dinamică a taskurilor, este mai flexibilă, dar comportă anumite 
complicaţii la nivelul executivelor, de multe ori nejustificate 
prin prisma cerințelor aplicațiilor. În majoritatea aplicaţiilor de 
informatică industrială, a doua alternativă este 
arhisatisfăcătoare [12]. 


Se menţionează că alocarea stivei pentru taskuri trebuie 
făcută cu o deosebită atenție; o subdimensionare a acesteia, în 
raport cu necesităţile, conduce la disfuncționalități care, de 
obicei, nu-şi trădează cauza decât prin ciudățenia cu care se 
manifestă. Stiva este folosită pentru găzduirea variabilelor 
locale ale taskurilor, pentru transmiterea parametrilor şi 
memorarea adreselor de retur la apelul de funcții, și pentru 
salvarea contextelor la ieşirea taskurilor din execuție fizică. 


Tranziţia creat — gata 


Prin această tranziție, se spune că se realizează activarea 
taskurilor, adică trecerea lor din stadiul de spectatori în stadiul 
de competitori pentru obținerea unității centrale în scopul de a 
se rula. Activarea taskurilor se poate realiza imediat, cu o 
anumită întârziere sau periodic . În toate cazurile, se impune 
a se face distincție între activare şi rulare, activarea 
nereprezentând altceva decât o cerere de rulare. 


Tranziţia gata — în execuţie 


Această tranziție este inițiată şi realizată exclusiv de către 
dispecerul de  taskuri, care acordă procesorul celui mai 


26 


îndrituit dintre taskurile aflate în starea para. Acesta este fie 
taskul cu cea mai mare prioritate -asta în cazul în care taskurile 
sunt prioritizate-, fie taskul care aşteaptă la procesor de cel mai 
mult timp, fie taskul devenit gata cel mai recent, fie un task 
ales aleator, etc., de la caz la caz. 


Este de subînţeles că reintrarea în rulare a unui task este 
precedată de restaurarea contextului său. 


Tranziţia în execuție — în aşteptare 


Prin această tranziţie, un task aflat în execuție iese din rândul 
taskurilor ru/abile, ca urmare a apariţiei în rularea sa a unei 
condiţii de blocare. 


Condiţia de blocare poate fi introdusă în mod direct, prin 
execuţia în cadrul taskului a unei directive prin care se solicită 
explicit autoblocarea, sau în mod indirect, prin execuţia unor 
directive a căror acţiune nu se poate finaliza la momentul în 
cauză, intervenind necesitatea de a se aştepta ceva; în ambele 
aceste alternative, părăsirea stării în execuţie se efectuează cu 
salvarea întregului context de rulare al taskului în cauză, astfel 
încât cl să poată fi reluat. 


Tranziţia în aşteptare — gata 


Această tranziție este realizată implicit, prin diverse 
mecanisme, atunci când un task ajunge să îndeplinească din 
nou toate condiţiile de rulare. 


Tranziţia gata — în aşteptare 


Tranziţia gata — în aşteptare a unui task se realizează ca 
urmare a execuţiei într-un alt task a unei directive prin care se 
solicită blocarea lui, dacă el era gata. 
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CAP, 2. STĂRILE TASKURILOR ... 


Tranziţia în execuție > gata 


Această tranziţie este realizată fie ca urmare a execuției în 
taskul în rulare a unei directive prin care el însuşi solicită să-şi 
întrerupă execuţia, fie drept consecință a unei întreruperi fizice, 
în a cărei rutină de deservire se face un apel la dispecerul de 
taskuri. În ambele cazuri, părăsirea stării în execuție se 
efectuează cu salvarea întregului context de rulare al taskului în 


cauză. 


Remarci: 

J. Sistemele în care taskurile pot pierde procesorul nu 
numai la propria inițiativă, ci şi ca urmare & unor 
apeluri la dispecer făcute din rutinele de tratare a 
întreruperilor se numesc sisteme preemplive. 

2. Sistemele în care taskurile nu pot pierde procesorul 
decât la propria inițiativă se numesc sisteme non- 


preemptive. 


Tranziţiile în execuție — creat, 
gata > creat, în aşteptare — creat 


Prin aceste tranziţii, se readuc taskurile în stadiul în care au 
alocată memorie pentru cod, date şi stivă, dar sunt inactive, în 
sensul că nu prezintă nici un interes pentru executiv în procesul 
de alocare a procesorului. Identificatorii atribuiţi taskurilor le 
rămân, însă, în continuare, asociați, indiferent despre care 
dintre cele trei tranziţii este vorba. 


Tranziţia în execuţie — creat se efectuează, în mod normal, 
atunci când rularea unui task se termină. Trebuie precizat, însă, 
că, în numeroase aplicaţii multitasking, taskurile sunt bucle 


infinite. 


Tranziţiile gata — creat şi în aşteptare — creat se 
efectuează doar în situaţii excepționale, cauzate de diverse 
erori. 
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Tranziţiile în execuție — necreat, 
Sata — necreat, în aşteptare — necreat 
creat — necreat 


Prin aceste tranziţii, se dezalocă taskurilor supuse lor 
memoria ce le-a revenit pentru cod, date şi stivă (eventual, 
zona de cod poate rămâne rezervată, în continuare, pentru a se 
facilita re-crearea respectivelor taskuri). De asemenea, prin 
cele patru tranziţii se determină disocierea taskurilor în cauză 
de identificatorii ce le-au fost atribuiţi la creare. 


Aceste tranziții se execută doar în situaţii excepționale, 
cauzate de diverse erori. 


În figura 2_1, se prezintă, sintetic şi sugestiv, întreaga gamă 
de posibilități de evoluție a taskurilor în spațiul stărilor. 
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Fig. 2.2_1. Evoluţia taskurilor în spaţiul stărilor. 
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CAP. 2. STĂRILE TASKURILOR ... 


REZUMAT 


Tashurile aplicațiilor multitasking ating, pe parcursul rulării 
acestora, diverse stări. 


Starea primordială, <de la “care pleacă orice. task, este 
“pocreat”. În această Stare. taskurile: ni Sunt. cunoscute: de 
executiv şi, “în principiu, nu aut alocată memorie; pot, însă, 
avea, pentru zonele de cod şi de date: singura tranzițiė posibilă 
din starea necreat este către Starea “creat”, 


Sarea “ereat? se. caracterizează: prin aceea că. taskurile 
aflate în ea mt atribui! un identificator. şi alocată memorie, atât 
pentru cod, căl și pentru date şi stivă. Tranziţiile posibile din 
starea “ereat sunt către stările “sata”, respectiv: ' ‘necreat”: 


Siarea gata” este starea: în care taskurile sunt- apte- de 
rulare, dar mi rulează efectiv doar pentru că procesorul este, 
pentru. momenti, ocupat de un-alt task... Tranziţiile normale din 
starea "gata" sui către una din stările "în execuție", respectiv 

"în aşteptare". Există, însă, şi sisteme care admit tranziția de la 
starea "gata" către starea "creat" sau chiar o. tranziție de la 
starea "gata" către starea "necreat' 


Starea. “în execuţie” este starea în care se află taskurile care 
rulează efectiv, având la dispoziție, pentru moment, procesorul. 
Tranziţiile normale din Starea "în executie" sunt către una din 
stările "gata"; respectiv. "în aşteptare: Există, însă, şi Sisteme 
care” admit tranziția de. la starea "în execuţie” călre. starea 


"creat". sau chiaro tranzitie de la starea "în execuţie” către 
Starea "necreat'.. 


Starea “în: aşteptare” sau "blocat" este starea în care ajunse 
un task care a fost în execuţie, dar.a devenit. inapt de rulare, 
înainte de ase încheia, prin:survenired în cadrul lui a unei 
condiții de blocare. Tranziţia normală din starea "în aşteptare" 
este către starea. "gata", Există, însă, şi sisteme care. admit 
tranziția de la starea. "în aşteptare” către starea "creat" sau 
chiar 0. tranziție: dë: la. Starea tîn “aşteptare” către. Starea 
"necreat:, 
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Se numesc sisteme preemptive sistemele în care taskurile pot 
pierde procesorul nu. numai. la propiia inițiativă, ci şi că 
urmare a uhor apeluri la dispecer făcute din rutinele de tratare 
a întreruperilor. 


Se numesc sisteme. -non-preemiplive sistemele: în. care 
taskurile: nu pol pierde procesorul decăt la propria. inițiativă: 


ÎNTREBĂRI: 


1). Dafiniți starea “necreut"”. 

2); În ce stări pot ajunge 'taskurile aflate în siared 
“necreat??. 

3): Definiţi starea “creat”. 

4). În ce stări. pot ajunge taskurile aflate în. stared 
“ereat”? 

5). Definiţi starea “gata”. 

6). În ce stări pot ajunge taskurile aflate în. star cal 
“gata”? | 

7). Definiţi starea 


că, 


în execuţie! 


8). În ce stări pot ajunge tasturile aflate în starea * 
execuție"? 
9). Definiţi starea “în aşteptare”. 
10). mce stări pot'ajunge taskurile aflate în starea “în. 
aşteptare"? | 
11). Definiţi noțiunea de sistem preempliv. 
12). Definiţi noțiunea de sistem non-pieempliv, 
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3 
COMUTAREA TASKURILOR 


Prin noțiunea de comutare a taskurilor, este desemnat 

. . . . pe iama yeaa 

ansamblul de acțiuni prin care se asigură ieşi 

unui task și intrarea în rulare a altii task; în anumite, situații, 

este posibil ca un task să iasă din rulare și tot el să fie cel care 
intră în rulare, în cadrul unui aceluiași proces de comutare. 


şirea din rulare a 


Comutarea taskurilor este realizată în cadrul unei funcții a 
executivului numită dispecer de taskuri (în engleză: scheduler). 
Ea comportă următoarele acțiuni: 

| 


a 


salvarea contextului taskului care iese din rulare 

- determinarea taskului care urmează să intre în rulare 

- restaurarea contextului taskului care urmează să intre în 
| rulare şi, implicit, introducerea în rulare a acestui 
task.. 


Contextul unui task reprezintă ansamblul informațiilor care 
fac posibilă rularea în. acelaşi. interval. de. timp. a mai multor 
Taskuri pe un unic procesor sau pe un număr de procesoare 
Strict mai mic decât numărul taskurilor, într-o manieră 
caracterizată prin aceea că taskurile sunt fragmentate dinamic, 
iar fragmentele lor -întrețesute conjunctural. Cantitatea și 
semnificaţia informaţiilor care constituie contextul unui task 
sunt dependente de filosofia în care a fost conceput executivul. 
Independent de aceasta, însă, câteva informaţii constituie, prin 
forța lucrurilor, nucleul ireductibil al oricărui context [20]. 


Aceste informaţii sunt: 


CAP. 3. COMUTAREA TASKURILOR 


34 


CAP. 3. COMUTAREA TASKURILOR 


- adresa instrucției cu care taskul urmează să-şi înceapă 
sau să-şi continue rularea; 

_ cuvântul de stare a programului; 

- adresa curentă în stiva taskului; 

- conținuturile registrelor procesorului -altele decât cele 
implicate în  pointarea instrucțiilor, găzduirea 
cuvântului de stare a programului şi pointarea stivei; 

- starea curentă a taskului. 


Soluţiile posibile de implementare a mecanismului de 
comutare a taskurilor pot fi imaginate doar în complexul de 
premize determinat de mediul de programare în care executivul 
este grefat şi de statutul adoptat pentru taskuri şi pentru 
dispecer în cadrul respectivului mediu [20]. 


În dezvoltarea care urmează, se va considera mediul de 
programare BORLAND C / C++ 3.1, sub sistemul de 
operare MS-DOS, pe calculatoare din clasa IBM-PC şi se va 
adopta pentru taskuri şi pentru dispecer statutul de funcţii. 
Rularea unui program multitasking va implica, în consecinţă, 
apeluri ale funcţiei dispecer din funcţii task şi apeluri de funcţii 
task din funcţia dispecer. Notând funcțiile task cu nume de 
tipul Tk, unde k este un număr natural, şi funcţia dispecer cu 
numele D, putem reprezenta această stare de lucruri astfel: 


uvertură > D >T; >D > ~ >D >T, >D >T; >D >.. 
> D >T >.. 


Prin uvertură s-a desemnat o parte a programului aflată în 
afara tuturor taskurilor, dintre ale cărei acțiuni singura care 
prezintă interes aici este cea sugerată: acțiunea de amorsare a 
sistemului multitasking propriu-zis, prin apelarea dispecerului. 


Este de subînțeles că, în lanțul de acțiuni reprezentat, pot 
apare şi situații de tipul: 


>T; >D >T; >D >T; > Th >D >T; >... 
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Pentru evitarea oricăror interpretări greşite în 
reprezentările de mai sus, se precizează că o notație de tipul 
"T" nu reprezintă decât în cazuri particulare întreaga 
funcție aferentă ei; de cele mai multe ori, aparițiile succesive în 
lanț ale unei asemenea notații, pentru unul şi acelaşi "k", 
desemnează porțiuni consecutive din punct de vedere logic ale 
funcției în cauză. 


Să luăm, acum, în considerare, din primul lanț de acțiuni 
menţionat, tronsonul: 


>D > 


Părăsirea execuţiei taskului T; şi lansarea în executie a 
dispecerului se poate face exclusiv prin apelul funcțici prin 
care dispecerul este implementat, 


Apelul funcțici dispecer poate fi fie programat în cadrul 
taskului T;, fie supratorțat, ca efect al unei întreruperi fizice, în 
cadrul rutinei de deservire a acesteia. i 


Principial, se poate spune, în definitiv, că această rutină se 
Chiar confundă cu funcția dispecer. Rezultă, atunci, că 
supraforțarea apelului acestei funcţii, în ambianța de 
programare considerată, se poate face prevăzând ca vector al 
întreruperii componentele CS-IP ale pointerului reprezentat de 
numele ei (se reamintește că în limbajul C, normat de ANSI, 
identiticatorii nume de funcţii primesc în mod implicit din 
partea compilatorului statutul de pointeri către funcția în 
cauză). 


Apelul programat al funcției dispecer se poate realiza în 
aceeaşi manieră ca și apelul supraforțat, dacă se recurge, pentru 
implementarea lui, la o întrerupere logică. De altfel, ar fi de-a 
dreptul "contravențional" să nu sc procedeze astfel, pentru că 
este de un firesc demn de a fi impus prin lege ca la intrarea în 
funcția dispecer stiva să fie la fel încărcată, indiferent de modul 
în care această funcţie a fost apelată. 
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Considerând, pentru iniţiere, contextul unui task limitat la 
ansamblul celor cinci informații menţionate şi ținând seamă de 
acțiunile "hardware" -vezi figura 3_]- efectuate cu ocazia unor 
întreruperi fizice sau logice de către calculatoarele pe care le 
avem în vedere, constatăm că primele două dintre aceste 
informaţii se găsesc automat în stiva taskului care tocmai a 
rulat (taskul T;, în cazul concret abordat), în momentul intrării 


în funcţia dispecer. 


SP 


componentele adresei instrucției 
(după cu care taskul întrerupt 
acceptarea şi-ar fi continuat rularea 
întreruperi) ] cuvântul de stare a programului 


SP 
(în : | 
momentul Fig. 3_1. Acţiunile hardware efectuate pe stivă cu ocazia 


întreruperii) unor întreruperi, în cazul microprocesoarelor INTEL 80x86: 


salvarea conținuturilor registrelor F, CS şi IP . 


Ar fi de dorit ca, prin mecanisme cât mai comode şi mai ales 
cât mai rapide în acţiune, şi celelalte informaţii care definesc 
contextul taskurilor să fie salvate tot în stivă. În mediul de 
programare considerat, se poate asigura uşor salvarea în stivă a 
conţinuturilor registrelor  microprocesorului prin simpla 
declarare a funcției dispecer de tipul interrupt. Într-adevăr, îr 
limbajul C, dacă o funcție este de tipul interrupt, la intrarea în 
ea se execută, ca prime instrucții-maşină, următoarele: 


push 
push 
push 
push 
push 


push 
push 
push 
push 
mov bp, DGROUP 


Tig. 3_2. Instrucţiile-maşină 
generate de compilatorul BORLAND C / C++ 
în debutul funcțiilor de tipul interrupt. 
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Este de subînțeles: la părăsirea funcțiilor de tipul interrupt, 
se asigură descărcarea stivei, atât de informaţiile încărcate în 
cadrul lor (BP...AX), cât şi de celelalte (7P, CS, F). 


Din figurile 3_1 şi 3_2, se poate deduce faptul că singurele 
registre al căror conținut nu este salvat în stivă ca 
urmare a apelului printr-o întrerupere a unei funcții de tipul 
interrupt sunt cele implicate în pointarea stivei: registrul SS şi 
registrul SP, adică: registrele care găzduiesc adresa curentă în 
stivă. De altfel, ar fi chiar un nonsens salvarea conţinutului 
unor registre în locaţii de memorie adresate în exclusivitate de 
ele însele. Într-adevăr, întrucât salvarea conținutului unui 
registru nu se face în alte scopuri decât pentru a pregăti 
încărcarea lui cu altceva, în cazul registrelor SS şi SP, când 
această încărcare s-ar realiza, nu s-ar mai putea şti la ce adrese 
din stivă se află conținuturile lor anterioare şi, fără cunoaşterea 
acestora, niciuna dintre celelalte informaţii salvate sub 
controlul lor nu ar mai putea fi recuperate. 


Se impune, aşadar, ca salvarea conținuturilor registrelor 
implicate în pointarea stivei, reprezentând adresa curentă în 
stivă, să se efectueze în locații de memorie predestinate. Pentru 
aceasta, este necesară definirea, pentru fiecare task, a unor 
variabile la care aceste conținuturi să fie atribuite. Evident, 
aceste variabile nu pot fi din clasele auto sau register. Din 
punct de vedere al locării pe care o asigură variabilelor, clasele 
static şi extern sunt ambele corespunzătoare. Clasa extern, 
oferă, însă, în plus-față de clasa static, p posibilitatea de de acces. 
la respectivele variabile -vizibilitatea lor, altfel spus- de 


oriunde din cadrul programului. iezii 


Fie ss şi sp numele generic al variabilelor destinate salvării 
conținuturilor registrelor SS, respectiv SP; aşa cum am spus, 
ele se vor regăsi în câte un exemplar aparte, pentru fiecare task. 
Se precizează că în C, registrele SS şi SP sunt accesibile atât 
pentru citire, cât şi pentru.sci in intermediul variabilelor 
rezervate 55, respectiv SP. 
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Informaţia din cadrul a ceea ce am considerat noi, pentru 
început, că reprezintă contextul unui task, referitoare la starea 
curentă a taskului respectiv, se distinge esențialmente. de 
toate celelalte patru informaţii conexe, prin faptul că ea 
nu este legată, prin definiție, cum suni acestea, de un 
registru al procesorului. Existenţa în sistem a acestei informații 
presupune definirea, corespunzător ei, a unci variabile căreia 
să-i fie atribuită. Din aceleași considerente menționate în 
expunerea făcută referitor la salvarea adresei curente în stivă, 
această variabilă se adoptă de clasă extern. Fie status numele 


acestei variabile. 


Tot ce s-a spus despre informația din contextul unui task 
referitoare la starea curentă a taskului este valabil pentru orice 
informații imaginabile ca elemente ale contextului, în 
completarea celor considerate. 


Am arătat, până aici, când, cum şi unde se realizează 
salvarea contextului taskului ce iese din rulare. Cu menţiunea 
că vom reveni asupra acestei probleme, să ne ocupăm, în 
continuare, de celelalte două acţiuni pe care am spus că le 
comportă comutarea taskurilor. 


Cronologic, acţiunea de salvare a contextului taskului ce iese 
din rulare trebuie să fie urmată de acţiunea de determinare a 
taskului ce intră în rulare. Această acțiune, care reprezintă, în 
fond, dispecerizarea taskurilor, va fi analizată detaliat mai 
târziu (vezi capitolul 4); ne limităm, aici, doar la-a admite că 
dispecerul nostru o asigură, fără a ne interesa, pentru moment, 


cum., 


Acțiunea de restaurare a contextului taskului ce intră în 
rulare debutează cu actualizarea variabilei status a acestui task, 
astfel încât ea să reflecte corect noua stare a acestuia. În 
continuare, se impune lăsarea în regim de conservare a stivei 
taskului care a ieşit din rulare şi reactivarea stivei taskului ce 
intră în rulare. Aceasta se realizează prin copierea în registrele 
SS şi SP ale procesorului, prin intermediul variabilelor sistem 
_S5, respectiv _SP, a valorilor variabilelor ss şi sp ale acestui 
fask. O dată realizat acest lucru, simpla părăsire a funcției 
dispecer, având în vedere că ea este de tipul interrupt, va 
asigura restaurarea registrelor taskului ce intră în rulare, prin 
descărcarea în ele a informațiilor prezente în stiva curentă. 
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Şi cum această restaurare vizează, în finalul ei, registrele 7P, 
CS şi F, ea va avea, ca efect implicit, repunerea efectivă în 
rulare a taskului în cauză (taskul Tj în cazul concret 
considerat). Iar cu aceasta, un ciclu de comutare a taskurilor 
este gata încheiat. 


Evident, lucrurile pot decurge aşa cum s-a arătat doar dacă 
taskul ce intră în rulare are deja informaţii adecvate în 
variabilele sale ss şi sp şi în stiva la care acestea conduc 
condiție presupusă mai sus -c drept: în mod tacit- a fi 
satisfăcută. Aşa şi este, de altfel, pentru taskurile care au 
beneficiat de cel puțin o repriză de rulare şi sunt încă 
nedezactivate şi nedistruse. Se pune, însă, întrebarea: cum și de 
către cine se asigură condiția menţionată la prima intrare în 
rulare a unui task? 


S-a arătat, la prezentarea stărilor taskurilor şi a tranzițiilor 
taskurilor între stări, că alocarea stivei pentru un task se 
efectuează cu ocazia creerii acestuia. În mediul de programare 
considerat, alocarea stivei presupune precizarea bazei 
segmentului de memorie în care ea este implementată și a 
adresei în cadrul segmentului, care o mărginește superior, În 
momentul în care se doreşte ca o stivă astfel alocată să devină 
activă, este necesar şi suficient să se efectueze încărcarea 
informației privind baza segmentului în registrul SS şi a adresei 
care marchează marginea superioară a respectivei stive în 
cadrul segmentului, în registrul SP. 


Informația privind baza segmentului de stivă aflat la 
dispoziția unui task, şi, în general, la dispoziția utilizatorului, 
este oferită de sistem prin variabila _user_ss. 


Adresa care marchează marginea superioară a stivei în 
cadrul segmentului este determinată în cadrul executivului, în 
funcție de lungimea solicitată de utilizator pentru stivă, "cu 
ocazia creerii taskului. 


Rezultă că, dacă la crearea unui task, s-ar inițializa 
variabilele ss și sp ale taskului respectiv cu informaţia privind 
baza segmentului de stivă, respectiv cu adresa care marchează 
marginea superioară a stivei acelui task în cadrul segmentului 
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în cauză, ar mai rămâne de asigurat, pentru ca lansarea în 
rulare să se efectueze după același mecanism ca şi repunerea 
în rulare, doar încărcarea zonci superioare a stivei astfel 
localizate, cu informaţiile care să constituie conținuturile 
inițiale ale registrelor procesorului puse în corespondență cu 
locaţiile acestei zone (BP, DI, SI, DS, ES, DX, CĂ, BX, AX, 
IP, CS, F). 


Dintre aceste registre, însă, nu toate trebuie să aibă un 
conţinut cu semnificaţie la demararea unui task. Astfel, în 
mediul de programare considerat, doar registrele BP, DS, ES, 
IP, CS, şi F trebuie iniţializate. 


În registrul BP, se impune încărcarea aceleiaşi valori ca și 
în registrul SP, întrucât el este folosit pentru pointarea 
variabilelor din clasa auto şi a argumentelor funcţiilor, locatate, 
şi unele și altele, în stivă. 


În registrul DS, se impune încărcarea informației privind 
baza segmentului de date aflat la dispoziţia taskului. Această 
informaţie este oferită de sistem prin variabila _user_ds. 


Similar, în registrul ES, se impune încărcarea informației 
privind baza segmentului extra aflat la dispoziţia taskului, 
informație care este oferită de sistem prin variabila _user_es. 


În registrele JP şi CS, se impune încărcarea componentelor 
adresei instrucției cu care taskul urmează să-şi înceapă rularea. 
Această adresă trebuie precizată de utilizator, cu ocazia creerii 
taskului. 


În registrul F, se impune încărcarea unei informații al cărei 
singur rol este de a asigura validarea întreruperilor, astfel încât 
orice task să-și debuteze rularea cu întreruperile validate. 
Această informaţie este, pentru procesoarele avute în vedere şi 
într-o exprimare corepunzătoare mediului de programare 
considerat, constanta 0x200. 


Se poate deduce, din cele de mai sus, că există posibilitatea 
ca toate inițializările despre care s-a vorbit să se efectueze cu 
ocazia creerii taskurilor, astfel încât, pentru dispecer, să nu mai 
prezinte interes dacă la un moment un task intră în prima sa 
repriză de rulare sau într-o alta, oarecare. 
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Pentru sistematizarea lucrurilor şi simplificarea exprimărilor, 
să considerăm contextul unui task ca o reuniune dintre un 
context fizic şi un context logic. 


Definim noţiunea de context fizic ca ansamblu al 
următoarelor informaţii: 


- conținutul registrului fanioanelor: F; 

- conținutul registrului segment de cod: CS; 

- conţinutul registrului pointer de instrucţie: ZP; 

- conţinutul registrelor ordinare: 4X, BX, CX, DX, ES, 
DS, SI, DI, BP. 


Contextul fizic al unui task este reprezentat sintetic în 
figura 3_3. 


IP AX [BX [CX |DX 


conținutul 
| starea registrului 
programului BP 
i baza i 
i aza conținutul 
i curentă a i i 
i J registrului 
i segmentului DI 
i de cod 
; adresa în conținutul 
i segment a registrului 
! următoarei SI 
i instrucții 
i conținutul baza curentă a 
registrului segmentului 
AX de date 
conținutul | | baza curentă a 
registrului segmentului 
BX extra 


conținutul conținutul 
registrului registrului 
CX DX 


Fig. 3_3. Contextul fizic al unui task. 
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Pentru a face, mai facilă operarea cu informațiile subsumate 


în noţiunea de context fizic, introducem un tip definit de dată 
special, pe care îl denumim CONTFIZ, prin următoarea 


declaraţie: sia 


typedef structi 
usint bp, di, si, ds, es, dx, Cx, bx, ax; 
unioni 
TASK_ADR cs_ip; 
struct 
usint ip; 
usint cs; 
Jeai; 
Jadr; 
usint f; 
}CONTFIZ 


Fig. 3_4. Tipul definit de dată CONTFIZ. 


Semnificația câmpurilor "bp", "di", "si", "ds", Yes”, "dx", 
"ex", “bx”, "ax", "ip", "es", "f" este evidentă. Cu "cai" s-a notat 
structura ce cuprinde componentele adresei instrucției cu care 
taskul urmează să-şi continue rularea, iar cu "adr" -uniunea 
dintre această structură şi o variabilă pointer de funcție TASK, 
numită TASK_ADR, introdusă prin declaraţia: 


typedef TASK (*TASK_ADR) (void) ; 


Cu TASK s-a notat sintagma void far cdecl, făcându-se uz 
de facilitățile pe care le oferă practic toate mediile de 
programare în C / C++, la nivelul preprocesorului lor: 


define TASK void far cdecl 


În aceste condiţii, o funcţie care implementează un task -de 
exemplu: taskul de achiziţie a datelor-, se va declara astfel: 


TASK achizitie (void); 
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Definim noțiunea de context logic minimal ca ansamblu al 
următoarelor informații: 
- adresa de lansare în execuţie / continuare a rulării 
taskului, runadr 
- starea curentă a taskului, status 
- conținutul inițial / din momentul ieșirii din rulare a 
taskului al registrului segment de stivă, ss 
- conţinutul iniţial / din momentul ieșirii din rulare a 
taskului al registrului pointer de stivă, sp 


Contextul logic minimal al unui task este reprezentat 
sintetic în figura 3_5. 


adresa starea conținutul inițial conținutul inițial 
de lansare / curentă / din momentul  / din momentul 
continuare ieşirii din rulare ieșirii din rulare 


a taskului a taskului 
al registrului al registrului 
segment de stivă pointer de stivă 


Fig. 3_5. Contextul logic minimal al unui task. 


La limită, aceste informații ar putea fi suficiente unui 
executiv de timp real. Totuşi, în practică, se dovedeşte util ca 
lor să li se adauge și altele, cum ar fi: 


- adresa în segment corepunzătoare marginii superioare a 
stivei taskului, zop_stk_m 

- adresa în segment corepunzătoare marginii inferioare a 
stivei taskului, bot_stk_m 

- prioritatea taskului, prior 

- timpul cât taskul este autorizat să rămână / să mai rămână 
în aşteptare, Sltime 

- dacă taskul a ajuns sau nu la fimeour, ca urmare a 
nescoaterii lui din starea în aşteptare în timpul 
prestabilit, to 

- dacă este sau nu autorizată preempția, preempflg 

- dacă taskul este sau nu activat, en_des 
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Informațiile zo şi sltime se folosesc astfel: Dacă un task se 
pune în starea în aşteptare cu deadline, atunci informația sa 
sltime se setează la timpul maxim cât el poate rămâne în 
respectiva stare, exprimat în perioade ale ceasului de timp 
real -numite "ficuri”-. La fiecare întrerupere de la ceasul de 
timp real, se verifică, pentru fiecare task, mai întâi, dacă este 
în aşteptare, iar apoi, în cazul afirmativ, dacă așteptarea este 
cu deadline. Dacă aşteptarea este cu deadline, atunci valoarea 
deadline-ului, înregistrată în slime, se decrementează cu o 
unitate, după care se testează dacă nu cumva, drept 
consecință, ea a ajuns nulă. Dacă da, atunci informaţia fo a 
taskului în cauză se poziţionează pe 1 şi taskul este scos din 
starea în așteptare şi trecut în starea gata. 


Informaţia preemflg se foloseşte astfel: Dacă se doreşte ca 
pe o porțiune a sa un task să fie non-preemptiv, atunci 
informaţia sa preemflg se poziţionează la O şi, prin aceasta, se 
face cunoscut dispecerului că nu trebuie să realizeze nici o 
comutare. 


Putem concluziona, acum, că la comutarea taskurilor, 
trebuie să aibă loc: 


o pedeo parte: 
a). Salvarea în stiva taskului ce iese din rulare a 
contextului fizic al său. 
b). Actualizarea unora dintre variabilele ce țin de 
contextul logic al taskului ce iese din rulare: sp, ss, status, 
sitime, to. 


e pede altă parte: 
c). Copierea valorilor unora dintre variabilele ce țin de 
contextul logic al taskului ce intră în rulare, în registrele 

corespondente: 


sp ———— în SP; 
via SP 

ss ——> în SS. 
via SS 

d) Actualizarea variabilei status a taskului ce intră în 
rulare: 

e) Instituirea / restaurarea contextului fizic al taskului ce 
intră în rulare, prin descărcarea stivei sale în registrele 
corespondente; este de subînțeles că, prin această 
operație, se produce implicit şi intrarea propriu-zisă în 
rulare a acestui task. 
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Aşa cum s-a menționat deja, operațiile a), respectiv e) se 
execută automat la apelul printr-o întrerupere a functiei 
dispecer -această funcție având tipul interrupt-, respectiv la 
părăsirea funcției dispecer. Celelalte operații -b), c), d)- trebuie 
executate prin instrucții explicite ale funcției dispecer. Pentru a 
se facilita satisfacerea acestui imperativ, se vor grupa 
variabilele runadr, status, ss, sp, sltime, to ca şi peemjlg, 
en_des, top_stk_m, bot stk m şi prior corespunzătoare unui 
task, într-o structură. Fie CONTLOG numele de tip definit 
atribuit acestei structuri. Înainte de introducerea lui efectivă, se 
impun câteva precizări referitoare la variabilele pe care el le va 
reuni: 


Variabila runadr, reprezentând adresa de lansare / 
continuare a unui task, va fi de tipul TASK_ADR, introdus 
mai sus. 


Variabila status va lua valori într-o mulțime de cardinal 
cinci, întrucât cinci este numărul stărilor pe care le pot atinge 
taskurile. Vom adopta, pentru această variabilă, tipul unsigned 
char, pe care îl vom referi, însă, printr-un nume mai scurt, 
uschar, definit astfel: 


4 define uschar unsigned char 


Este acesta un loc potrivit pentru a introduce și codurile pe 
care dorim să le atribuim diverselor stări. Vom folosi, de 
asemenea, directiva define a preprocesorului: 


tdefine NECREAT 0 
#define CREAT 1 
define GATA 2 


define EXECUTIE 3 
define BLOCAT 4 


Variabilele ss şi sp fiind destinate să memoreze conținuturile 
unor registre pe 16 biţi, este firesc să fie, atunci, de tipul 
unsigned short. Vom referi acest tip prin numele usshort, 
definit astfel: 
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4define usshort unsigned short 


Variabila sltime se impune a fi pe 32 biţi, deci, de tipul - 
unsigned int. Vom referi acest tip prin numele usini, definit 


astfel: 


define usint unsigned int 


Celelalte variabile se pretează, în mod evident, să fie pe 8 
biti şi; în consecință, le vom face de tipul uschar. 


Structura CONTLOG va fi, deci, introdusă astfel: 


typedef structi 
TASK_ADR runadr; 
uschar status; 
uschar prior; 
usshort ss; 
usshort sp; 
usshort up_stk_m; 
usshort bot_stk_m; 
usint sltime; 
uschar to; 
uschar preempflg; 
uschar en_des; 

) CONTLOG; 


Întrucât fiecare task are asociată o variabilă de tipul 
CONTLOG, este firească gruparea într-un tablou a tuturor 
acestor variabile. Dimensiunea tabloului va fi, evident, egală cu 
numărul maxim al taskurilor pe care le poate accepta 
executivul. Folosim simbolul MAX TSK pentru desemnarea 


acestui număr: 


4define MAX TSK 100 
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Fie _contlog numele tabloului variabilelor de tipul 
CONTLOG. Acest tablou va fi declarat astfel: 


CONTLOG _contlogIMAX_TSK]; 


O singură problemă se pare că a mai rămas nerezolvată legat 


de comutarea taskurilor: cum se poate obţine, din cadrul 
funcţiei dispecer, accesul, în stivă, la unele informaţii ce ţin 
de contextul fizic al taskului ce urmează, la un moment, să 
intre în rulare? 


Soluţia acestei probleme este oferită de însuşi mecanismul 
de transmitere a argumentelor între apelant și funcția apelată, în 
limbajul C. Pentru revelarea acestui mecanism, să considerăm 
următorul program: 


include "stdio,h" 
include "stdlib.h" 
tinclude "conio,h" 
iidefine usint unsigned int 


typedef structi 
usint bp, di, si, ds, es, dx, cx, bx, ax; 
union{ 
TASK_ADR cs_ip; 
struct i 
usint ip; 
usint cs; 
)cai; 
Jadr; 
usint f; 
}CONTFIZ; 


CONTFIZ x; 


(se continuă) 


47 


CAP. 3. COMUTAREA TASKURILOR 


CAP. 3. COMUTAREA TASKURILOR 


void scheduler (usint pbp, 


usint psi, 
usint pes, 
usint pex, 


usint pdi, 
usint pds, 
usint pdx, 
usint pbx, 


push ax 


mov ax, 9 


; se pune pe stivă valoarea argumentului 10 


; al funcției scheduler) 


usint pax, usint pip, mov ax, 8 pune pe stivă valoarea argumentului 9 
usint pes, usint pf){ push ax ; al funcției scheduler) 

x.bp=pbp; 

x.di=pdi; mov ax, 7  ;se pune pe stivă valoarea argumentului 8 

x.si=psi; push ax ; al funcţiei schedeler() 

x.ds=pds; 


x.es=pes; mov ax, 6  ;sẹ pune pe stivă valoarea argumentului 7 
x.dx=pdx; push ax ; al funcției scheduler() 
X.CX=pCX; ' 
2 .bx=pbE; i mov ax, 5 ; se pune pe stivă valoarea argumentului 6 
+. ax=pax; i push ax ; al funcţiei scheduler() 
|  x.ip=pip; = 
| x.es=pcs; iki mov ax, 4  ;sepunepestivă valoarea argumentului 5 
| x. f=pt i i push ax ; al funcţiei scheduler()- 
pă i 
| void main (void) { H | mov ax, 3 ;sepune pe stivă valoarea argumentului 4 
| scheduler (0,1,2,3,4,5,6,7,8,9,10,11); H | push ax ; al funcției scheduler() 
| H 
i i 


mov ax, 2  ;sepunepestivă valoarea argumentului 3 
push ax ; al funcţiei scheduler() 


i Compilând acest program pe model large şi analizând, apoi, 
codul obţinut, cu ajutorul debugger-ului, vom constata că 
programul principal, respectiv funcția scheduler() se prezintă în 


mov ax, 1  ;scpunepestivă valoarea argumentului 2 


push bp 
mov bp, sp 


| limbaj de asamblare după cum urmează: | Bush ax ; al funcţiei scheduler() 

F H 

| 

| xor ax ; se pune pe stivă valoarea primului argument | 
| RAMUL PRINCIPAL e | 
| PROGRAMU. push ax ; al funcţiei scheduler 


; se efectuează apelul funcţiei scheduler: 
push cs 

se pregăteşte apelul funcţiei scheduler(): call scheduler 
; se pune pe stivă valoarea ultimului argument 


; al funcţiei scheduler() (bis! 110) 


mov ax, b 
push ax 


; se descarcă stiva: 
add sp,18 
pop bp 


; se pune pe stivă valoarea argumentului 11 
; al funcţiei scheduler() (a16=10:0) 


mov ax, a 


push ax ; se revine în apelantul programului principal: 


ret 


(se continu 
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FUNCȚIA VOID SCHEDULER() 


push bp 
mov bp, Sp 


ax, [bp+6] ; se face x.bp= valoarea primului 
x], ax ; argument al funcţiei scheduler() 


ax, [bp+8] ; se face x.di= valoarea argumentului 2 
028e], ax ;al funcţiei scheduler() 


ax, [bpta] ; se face x.si= valoarea argumentului 3 
[0290], ax ;al funcţiei scheduler() 


ax, [bp+c] ; se face x.ds= valoarea argumentului 4 
[0292], ax ;al funcţiei scheduler() 


ax, [bprel ; se face x.es= valoarea argumentului 5 
[0294], ax ;al functiei scheduler() 


ax, [bp+10] ; sc face x.dx= valoarea argumentului 6 
10296], ax ;al funcţiei scheduler() 


ax, [bp+12] ; se face x.cx= valoarea argumentului 7 
[0298], ax ;al funcţiei scheduler 


ax, [bp+14] ; se face x.bx> valoarea argumentului 8 
[029a], ax ;al funcţiei scheduler() 


ax, [bp+16] ; se face x.ax= valoarea argumentului 9 
[029c], ax ;al funcției scheduler() 


ax, [bp+18] ; se face x.ip> valoarea argumentului 10 
[029e], ax ;al funcției schediuler() 


; se face x.cs= valoarea argumentului 11 
; al funcţiei scheduler() 


; se face x.f= valoarea ultimului 
ax  ; argument al funcţiei scheduler() 


Dacă redefinim, acum, funcţia scheduler(), astfel încât 
ea să nu mai fie void scheduler(usint pbp, ..., usint pf), ci 
void interrupt scheduler(usint pbp, ..., usint pf), atunci vom 
constata că textul ei va fi tradus la expresia: 


FUNCT. 


push ax 


push bx 
push cx 
push dx 


push es 


push ds 
push si 
push di 


push bp 


mov bp,5425 


mov ds, bp 

mov bp, sp 

mov ax, [bp] ; se face x.bp= valoarea ajunsă în stivă 
mov [_x], ax ; din registrul bp 


mov ax, [bp+2]  ; se face x.di= valoarea ajunsă în stivă 
mov [028e], ax ;dinregistul di 


mov ax, [bp+4] ; se face x.si= valoarea ajunsă în stivă 
mov [0290], ax ;din registrul si 


mov ax, [bp+6] ; se face x.ds= valoarea ajunsă în stivă 
mov [0292], ax ; din registrul ds 


mov ax, [bp+8] ;se face x.es= valoarea ajunsă în stivă 
mov [0294], ax  ;din registrul cs 
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ax, [bpta] ; se face x.dx= valoarea ajunsă în sti 
[0296], ax ;dinregistrul dx 


ax, [bp+e] ;se face x.cx= valoarea ajunsă în stivă 
[0298], ax ; din registrul cx 


ax, [bpte] ; se face x.bx= valoarea ajunsă în stivă 
[029a], ax ;dinregistrul bx 


ax, [bp+10] ; se face x.ax= valoarea ajunsă în stivă 
[029c], ax ; din registrul ax 


ax, [bp+12] ;se face x.ip= valoarea ajunsă în stivă 
[029e], ax ;din registrul ip 


ax, [bp+14] ; se face x.cs= valoarea ajunsă în stivă 
[02a0], ax ;din registrul cs 


ax, [bp+16] ; se face x.f= valoarea ajunsă în stivă 
[02a2], ax ; din registrul f 


bp 


di 
si 
ds 
es 


Comentariile aferente textului în limbaj de asamblare al 
funcției void interrupt scheduler() au fost scrise în ipoteza că 
funcția este apelată prin mecanismul întreruperilor -ea fiind, 
aşadar, în postura de handler-, mecanism care, după cum se 
cunoaşte, reacționează la o cerere de întrerupere depunând, mai 
întâi, pe stivă, conținutul registrului / şi abia după aceea 
apelând rutina aferentă întreruperii în cauză. 
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Singurul lucru pe care îl mai avem de făcut pentru a putea 
trece, în sfârşit, la scrierea textului funcţiei dispecer, este să 
presupunem că această funcție determină indexul taskului ce 
urmează a intra în rulare, printr-o funcție denumită nexz_Jap, 
de tipul unsigned char -referit prescurtat prin uschar-, şi fără 


argumente: 


uschar next_lap(); 


Fig. 3_6. Funcţia de determinare a următorului task ce intră în rulare 
a, ae Re Tetine a i a iii 
(ap este prescurtare ds la-7is/ă-de-așteptare-lr procesor). 


Este de subînțeles că această funcţie va alege un task în 
vederea rulării dintre taskurile aflate în starea gata sau, o dată 
în plus, taskul aflat în starea execuţie. Cunoaşterea numărului 
taskului aflat la un moment în rulare fiind necesară în 
numeroase locuri în cadrul executivului, se foloseşte, pentru 
memorarea lui, o variabilă globală, denumită _rasfe cr7. 


uschar _task_ crt; 


Fig. 3_7. Variabila de memorare a numărului taskului aflat curent în 


mlare 


În sfârşit, putem trece, acum, la scrierea textului funcţiei 
motive lesne de înțeles, 


dispecer, adoptând pentru ea, din 
numele scheduler: 


HANDLER scheduler (usint bp, 
usînt: si, 
usint es, 
usint:cx, 
usintiax, 
usint cs, 

static CONTLOG *p; i 
static uschar i; 
static usint aux; 


usint di, 
usint ds, 
usint: dx, 
usint: bx, 
usint; ip, 
usint:£) 1 


(se continuă) 


Fig. 3_8. Textul C al funcţiei scheduler() -partea 1-. 
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For (i=0;i<MAX_TSK; i++) { i 
if (search _ltb(:)) 1 laa Act 
p=& contlogiii A 
i£ (p->sltime!=0) | 
if (--p->sltime==0) { 
p->to=1; 
_makeup (4); 


î£ ( ( (aux>=LIM_INF) && (aux<=LIM_SUP) ) &6 (!_£ltop) 
&& (_contlog [_tsk_crtl „preempf1lg) ) { 
p=&_contlog[_tsk_crt]; 
p->sp=_SP; i 
p->ss=_SS; 
tsk_crt=next_lap () ; 
p=6_contlog [_ksk_crt]; 


_SP=p->sp; | 
_SS=p->ss; i 
p->statussEXECUTIE ; i 
p% i 
~ (_vtvi 181) (); i 


3 


Fig. 3_8. Textul C al funcţiei scheduler() -partea a Il-a-. 


Se precizează că funcția wakeup() are rolul de a trezi 
(debloca) taskul al cărui index îi este transmis drept parametru. 
Evident, prin acţiunea funcţiei wakeup(), taskul referit este 
trecut din starea blocat în starea gata. 


Simbolii  LIM INF, respectiv LIM_SUP delimitează 
inferior, respectiv superior domeniul de adrese de segment de 
cod pentru care este garantat că nu sunt pe post de offset 
pentru coduri de funcţii sistem nereentrante. 
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După cum se va vedea, dispecerizarea taskurilor este ceva ce 
trebuie făcut pe de o parte periodic, la fiecare întrerupere de la 
ceasul de timp real, iar pe de altă parte sporadic, atunci când un 
task nu-și mai poate avansa sau nu mai vrea să-şi avanseze 
activităţile. 


Funcţia scheduler()_dată mai sus este concepută, < evident, 
pentru a comuta taskurile în regim periodic. Ea va juca ro rolul de 
faridier de mirerupere pontu între eruperile de la ceasul de timp 
real, fiind apelată de fiecare dată când o astfel de întrerupere 
este activată. 


Pentru comutarea —speradieă se impune a se avea o 
instanţiere specifică a dispecerului, sensibil mai simplă decât 
cea de mai sus, dedicată apelului programat. Ei nu i se mai 
pretinde, spre exemplu, să verifice dacă există taskuri blocate 
cu timeout şi, în cazul afirmativ, să actualizeze timpul rămas 
până la atingerea limitei de timp de blocare, respectiv să 
efectueze deblocarea. De asemenea, celei de-a doua instanțieri 
a dispecerului nu i se mai cere să verifice dacă este pe cale să 
se realizeze o comutare în timpul rulării unei funcţii de 
bibliotecă matematică în virgulă flotantă sau unei funcții sistem 
nereentrante sau unei secvențe de program nepreemptive. 


Textul C al dispecerului cu apelare programată este redat în 
figura 3_9. 


HANDLER sched (void) { 
; static CONTLOG *p; 
—cli(); 
p=&_contlog[_tsk_crt]; 
p->sp=_SP; 

p->ss=_S8; 
_tsk_crt=next_lap(); 
p=&_contlog[_tsk_crt]; 
_SP=p->sp; 

_SS=p->ss; 
p->status=EXECUTIE ; 


Fig. 3_9. Textul C al funcției sched). 
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REZUMAT 


Se nimeşte context ansamblul. informatiilor. sistem cu 
inslanțiere specifică la nivelul fiecărui task, pe baza cărora se 
asigură posibilitatea ca taskurile să fie rulate- în. regim 
concurential. prin... fragmentarea ` lor. ṣi înirețeserea 
fragmentelor. S : 


Se numeste. context fizic. partea informațiilor: ce constituie 
contextul sabvabilă 7 restaurabilă < prin mecanisme ale 
procesorului sau compilatorului. 


Se numeşte context logic partea informaţiilor ce constituie 
contexnil nesalvabilă / nerestaurabilă prin mecanisme. ale 
procesor ului sau compilator uli 


utilizării. pocaoo dor INTEL 80x86. şi a 
w C (din. „mediile de programare. TURBO, 


iar con extul logic infol -mații de genul: 
( a adresa de lansare în execuție a taskuluui;. 

- "starea curentă a taskului; : 

©- conținutul inițial al registrului pointer de stivă; 

- conținutul curent al registrului segment de stivă SS; 
| uzi conținutul curent al registrului pointer de stivă SP. 


"Se numeşte comutare a taskurilor ansamblul de acțiuni prin 
care se asigură ieşirea din rulare a unui task şi intrarea. în 
rulare a altui task. Comutarea incumbă: ; 

'- salyarea contextului taskului care iese din ruler C; 

-determinarea taskului care urmează să intre în rilar e; 

- “restaurarea contextului taskului care uri MEAZA. să intre 
în rulare. ; 


Se numeste dispecer (în. engleză “scheduler *) entitatea din 
componență executivului în MSAT reinată cu realizarea comutării. 
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i 5) 


` ÎNTREBÂRI: 


1): Ce se înțelege prin context al unui task? 

2). Ce este contextul fizic? 

3). Ce este contextul logic? ; 

4). Ce. cuprinde contextul fizic în cazul utiliză 
procesoarelor INTEL $0x86 şi a compilatoarelor: C 
(din. mediile de programare: TURBO, BORLAND 

er)? | 
Ce. cuprinde contextul logic în cazul: utilizări 
procesoarelor INTEL 80x86 şi a. compilatoarelor c| 
(din mediile. de programare TURBO, BORLAND, | 
etc.) 2. 

6). Ce se întelege prin comutare ataskur ilor? 
7). Ce acțiuni incumbă comutarea taskurilor?: 
8): Ce este dispecertl?: : 

9). Ce tipuri de comutări ex 5 

10). Dați o implementare C comi 

însărcinat Cu comutarea. perio ică 

11). Daţi o implementare. C comentată a 

însărcinat Cu comularea spor adică. 


dipecut f 
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4 
DISPECERIZAREA TASKURILOR 


S-a văzut, până aici, că într-un sistem în timp real cu 
multitasking, mai multe taskuri sunt, de obicei, în competiţie 
pentru a accede la procesor în scopul rulării lor. De asemenca, 
s-a arătat că este sarcina dispecerului de a. efectua, într-o 
sesiune de comutare, alegerea unuia dintre taskuri, în vederea 
rulării sale. 


Ansamblul de acţiuni prin care se realizează această alegere 
constituie procesul de dispecerizare a taskurilor. La baza 
acestui proces, stă un algoritm adoptat în faza de proiectare a 
executivului. Atât algoritmul în sine, cât şi manicra în care el 
este implementat, afectează în măsură considerabilă 
performanțele executivului şi ale  produselor-program 
dezvoltate cu ajutorul lui. 


In strânsă legătură cu destinaţia lor, executivele realizează 
dispecerizarea într-o variantă sau alta. Variantele cel mai 
frecvent întâlnite sunt următoarele [4]: 


4.1. Dispecerizarea prin rotaţie 


Această variantă de dispecerizare presupune existența unei 
liste unice de așteptare la procesor (reamintim prescurtarea /ap 
pentru listă de așteptare la procesor), în care sunt "înscrise" 
toate taskurile rulabile la un moment, adică: taskurile aflate în 


starea gata. 
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În situația concretă surprinsă de model, se remarcă 
următoarele: 

- taskul 07 este în rulare şi ocupă, în consecință, ultima 
poziție în lap; 

- taskul 01l este la iminența intrării în rulare, ocupând 
prima poziție în lap; 

- taskurile 06, 04, 09 aşteaptă, în această ordine, intrarea 
lor în rulare, după satisfacerea taskului 01; 

- taskul 05, după ce s-a aflat în rulare, a fost exclus din 
lap, blocându-se; 

- taskul 03, devenind rulabil, va fi adăugat în /ap, aşa 
cum se arată în figura 4.1_2. 


Toate operațiile de adăugare a unui nou task în listă se 

x ; A 
efectuează în capul acesteia, prin crearea unui nou nod în fața 
celui aflat în prima poziţie de până la momentul adăugării. 


Dispecerul alege, întotdeauna, pentru introducerea în rulare, 
taskul pe care-l găseşte în prima poziţie a listei. Odată cu 
introducerea în rulare a unui task, dispecerul asigură, implicit, 
şi trecerea acestuia în coada listei, deci în ultima ei poziţie. 
Evident, această trecere se face astfel încât, drept consecință a 
ei, toate celelalte taskuri să capete o poziție în listă cu o unitate 


mai avansată. 


Când un task aflat în rulare este supus unui proces de 


Sc poate subînțelege că lista de așteptare la procesor este una 


dai prima penultima 
e tip circular. ; poziți iți 
p ultima ||P? ne poziție 
poziţie (cap 
- listă) 


Modelul  dispecerizării prin rotație este reprezentat în 
figura 4.1_1. 


A intrare taskuri devenite rulabile 


comutare, fără ca acest lucru să se datoreze dezactivării sau ieşire 
suprimării lui, în fața sa stau două alternative. În prima dintre arse 
ele, presupunând că el îndeplineşte, în continuare, condiţiile de nerulabile-a- 
rulare, i se asigură rămânerea normală și statutul comun în lista (de 

s bary A = lu 

aşteptar rocesor. În a doua alternativă, presupunând că ASR : f 
de aşteptare (A PIIGes CĂ $ Sa PAVA POTE 3 askul 5) prima penultima 
taskul nu mai îndeplineşte condiţiile de rulare, blocându-se, ultima | Pozitie poziţie 
dintr-un motiv sau altul, se produce eliminarea sa din lista de poziţie (cap 
aşteptare la procesor și "înscrierea" pe o altă listă -łtb: lista ! listă) 
taskurilor blocate- , alături de alte taskuri, aflate în aceeași | intrare taskuri devenite rulabile 
stare. i ` p Ka seede 
i Fig. 4.1_1. Modelul dispecerizării prin rotație. 
Evident, și în cazul în care taskul în rulare este supus unui i 
proces de comutare datorat dezactivării sau suprimării sale, se i 
produce eliminarea sa din lista de aşteptare la procesor, dar el i eu ate punct inserare noi taskuri 
nu mai este înscris niciunde ca blocat, ci trecut în starea creat, | i i 
H VEI! 

j à 3 i A Y 
respectiv recreat. : nerulabile ï 03. je Ql i 06 ikan 04 [a—L09 H 


Fig. 4.1_2. Evoluţia situaţiei din figura 4.1_1, 
în urma inserării în /ap a taskului 03. 
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Presupunând, acum, că se produce un proces de comutare, în 

condițiile în care taskul 07 rămâne, în continuare, rulabil, se va 
S p fă za A A. 
ajunge în situaţia reprezentată în figura 4._3. 


ieşire punct inserare noi taskuri 
taskuri 
devenite y 
į jat 
nerulabile-ad R oog hH or-o Lo] 
| 
prima penu lti ima 
: poziţie poziţie 
ultima 
zitie (cap 
POZLEA| listă) 


A intrare taskuri devenite rulabile 


Fig. 41_3. Evoluţia situației din figura 4.1_2, 
în urma unui proces de comutare f 
(s-a presupus că taskul 07 a rămas, în continuare, rulabil). 


Realizarea dispecerizării prin rotaţie necesită gestionarea 
unei liste circulare de întregi foarte scurți -altfel spus: de tipul 
caracter-, reprezentând indexurile taskurilor rulabile, adică 
indexurile taskurilor aflate în starea gata. Din punct de vedere 
principial, un nod al unei asemenea liste va conţine, pe lîngă 
indexul unui task, şi un pointer către următorul nod, aşa cum se 


evidenţiază în figura 4.1_4. 


n 


; = n | 
ultima =] 0 
poziție 


(coadă | = P 


listă) 


punct 
primă inserare 
pozitie nod nou 
(cap listă) 
Fig, 4.1_4. Reprezentarea listei circulare de așteptare la procesor. 
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În această figură, s-au folosit notaţiile: 


- m,n, 0, p: pentru indexurile taskurilor aflate în listă 
- m: pentru indexul taskului aflat în rulare 
- p: pentru indexul taskului care urmează să intre în rulare 


void ins_lap(uschar ind _tsk) 
/* inserează în /ap taskul cu indexul ind _tsk */ 


void elim_lap(uschar ind _tsk) 
/* elimină din /ap taskul cu indexul jid tsk */ 


uschar next lap(voicd) | 
determină și returnează indexul taskului aflat în capul /ap * | 


void init_lap(void) 
/* iniţializează lista de așteptare la procesor */ 


Fig. 4.1_5. Funcţiile de gestionare a listei de aşteptare 
la procesor -cazul dispecerizării prin rotaţie. 


Având în vedere faptul că numărul maxim al taskurilor pe 
care le acceptă executivul este cunoscut şi, în cazurile practice 
avute în vedere de noi, relativ mic -uzual: de ordinul unităților, 
zecilor sau, oricum, nu mai mare de 254 (ne amintim, l-am 
presupus reprezentat de simbolul MA4X_7S5K)-, lista poate fi 
implementată sub forma unui tablou cu MAX 7SK+7 
elemente. Un element al tabloului, împreună cu indicele său 
vor reprezenta un nod al listei. Indicele va avea semnificația 
de index al taskului aferent nodului, iar elementul va avea ca 
valoare indexul taskului ce-i succede în listă taskului precizat 
de indice. Elementul de indice MAX_7SK avea un rol special, 
şi anume: va conţine indexul taskului din coada listei, deci 
indexul taskului aflat în rulare. Indexul MAX 7SK-/ va fi 
atribuit unui task de fond, rulabil non-stop, creat în mod 
implicit cu ocazia iniţializării executivului şi introdus în rulare 
atunci şi numai atunci când nu este găsit rulabil nici un alt 
task. 
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În baza acestor precizări, pentru situațiile din figurile 4.1_1, 
4.1_2 şi 4.1_3, tabloul care implementează lista de aşteptare la 
procesor va arăta, în ipoteza că MAX TSK=10, aşa cum se 


ilustrează în figurile 4.1_6, 4.1_7, respectiv 4.1_8. 
MAX_TSK 
4 96| i or oa 0707 
00 01 02 03 04 05 06 07 08 09 10 


Fig. 4.1_6, Tabloul corespunzător listei de așteptare la procesor, 
pentru situația din figura 4.1_l. 


MAX_TSK 
| 06|. [o1[]09 04.03 [07.07 


00 01 02 03 04 05 06 07 08 09 10 


Fig. 4.1_7. Tabloul corespunzător listei de așteptare la procesor, 
pentru situația din figura 4.1_2. 


MAX_ TSK 


Foe papori [04 os JE Eoo 
00 01 02 03 04 05 06 07 08 09 10 


Fig. 4.1_8. Tabloul corespunzător listei de aşteptare la procesor, 
pentru situația din figura 4.1_3. 


Folosim numele _/ap pentru variabila tablou prin care 
implementăm lista de aşteptare la procesor şi îi asigurăm 
statutul de variabilă globală, cu locare statică, declarând-o în 
afara oricăror acolade (a se citi: oricărui bloc): 


volatile uschar _lap[MAX_TSK+1] ; 


Fig. 4.1_9. Declararea variabilei tablou prin care se 
implementează lista de aşteptare la procesor. 


Să abordăm, acum, mecanismul de lucru al celor patru 
funcții de gestionare a listei. 
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Funcţia ins_lap() 


În ipotezele de lucru instituite, inserarea unui task în lista de 
aşteptare la procesor comportă următoarele acţiuni: 


1. determinarea indicelui elementului de tablou 
corespunzător taskului aflat în coada listei 

2. copierea elementului cu indicele determinat în pasul 1 în 

elementul cu indicele egal cu indexul taskului de inserat 

înscrierea indexului taskului de inserat în elementul 

corespunzător taskului aflat în coada listei 


U 


Având în vedere cele menționate, rezultă următorul text 
pentru funcţia ins_lapQ: 


void ins_lap(uschar ind _ tsk) 4 
2 _laplind tsk]= _lapl_lap[MAX_TSK]] ; 
3 _lap[_lap [MAX _TSK] ]=ind_tsk; 
4 


iei ins_lap() -cazul dispecerizării prin rotaţie, 
cu task de fond. 


Funcţia elina_lap( 


În ipotezele de lucru instituite, eliminarea unui task din lista 
de aşteptare la procesor comportă următoarele acțiuni: 


1. identificarea elementului de tablou în care este înscris 
indexul taskului ce trebuie eliminat 

2. copierea în elementul determinat în pasul | a 
elementului corespunzător taskului de eliminat (adică, a 
elementului cu indicele egal cu indexul taskului de 
eliminat) 

3. înscrierea în elementul corespunzător taskului de eliminat 
a valorii MAX TSK, pentru a semnala că respectivul task 
nu mai este prezent în listă sau, în alți termeni spus, 
pentru a semnala că el nu are succesor (reamintim: 
indexul de task mâxim este MAX_7SK-7 şi el corespunde 
taskului de fond). 
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4. actualizarea taskului din poziţia de coadă de listă, dacă a 
fost de eliminat tocmai taskul aflat curent în această 
poziție; noul task coadă de listă va fi, fireşte, 
predecesorul celui vechi -nimeni altul decât taskul în 
elementul de tablou corespunzător căruia a fost găsit 
indexul taskului de eliminat 


Având în vedere cele menţionate, rezultă următorul text 
pentru funcţia efim_lap(): 


void elim lap(uschar ind _tsk) [ 

uschar i=0; 

while ( (_lapii] !=ind_tsk) && (î<MAX_TSK) ) ( 
iks 


if(i!=MAX_TSK){ 
_lepli]=_lap[ind tsk]; 
_laplind_tsk]=MAX_TSK; 

i£ (_Lap [MAX_TSK]=ind_tsk) { 
10 _lap[MAX_TSK]=i.; 


1 
2 
3 
4 
5.) 
6 
7 
8 
9 


j 
i 
i 
i 


Fig. 4.1_11. Textul funcției e/im_lap() 
-cazul dispecerizării prin rotație, cu task de fond. 


Funcţia next_lapQ 


Această funcție are sarcina de a determina și indica 
succesorul taskului aflat în rulare. Acest succesor este tocmai 
taskul aflat curent în capul listei (taskul aflat în rulare ocupă, 
reamintim, poziţia din coada listei). Chiar dacă această 
afirmaţie este categorică, nu trebuie reprimată întrebarea: Oare, 
întotdeauna? 
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Răspunsul la această întrebare este "nu": nu, în situația în 
care în capul listei este găsit tocmai taskul de fond -ne 
reamintim: avem ca ipoteză de lucru existența în sistem a unui 
asemenea task-. De ce nu? Pentru că taskul de fond este unul 
cu rol auxiliar şi nu ar fi raţional ca cl să acceadă la procesor în 
mod egal cu taskurile propriu-zise. De altfel, s-a şi spus mai 
sus că menirea taskului de fond este să intre în rulare atunci şi 
numai atunci când nici un alt task nu este găsit rulabil. 

În situaţia în care în capul listei este găsit tocmai taskul de 
fond, atunci se va considera drept următorul în lista de 
aşteptare la procesor succesorul său. În acest fel, într-adevăr, 
acest task special care este taskul de fond va intra în rulare doar 
atunci când îşi va succede sie însuşi, lucru întâmplabil, evident, 
numai dacă el este singur în lista de aşteptare la procesor. 


Prin acţiunea funcției nexr_/ap(), taskul aflat în capul listei 
este trecut în coada acesteia. Cu această ocazie, se produce, 
implicit, şi avansarea celorlalte taskuri în cadrul listei, cu o 
poziție. Este de subînţeles că atunci când un singur task este 
rulubil, el joacă atât rolul de cap de listă, cât şi rolul de coadă 
de listă. 


In concluzie, funcția next lap) va comporta următoarele 
acțiuni: 


1. determinarea indexului taskului din coada listei 

2. dacă elementul cu indicele egal cu indexul taskului din 
coadă are valoarea diferită de MAX_7SK-7, atunci: 
copierea în elementul de indice MAX_TSK a elementului 
cu indicele egal cu indexul taskului din coadă 
dacă elementul cu indicele egal cu indexul taskului din 
coadă are valoarea egală cu MAX TSK-}, atunci: 
copierea în elementul de indice MAX_7SK a elementului 
cu indicele egal cu MAX_TSK-1 

3. returnarea noii valori a elementului de indice MAX _7SK 
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Textul funcţiei next _lap() este următorul: 


uschar next_lap (void) | 
if(_lap[_lap[MAX_TSK] ] !=MAX_TSK-1) { 
lap[MAX_TSK]= _lap|_lap[MAX_TSK]]; 


} 
else{ 
lap[MAX_TSK]= _lap[MAX_TSK-1]; 


} 
return (_lap ÎMAX_TSK]) ; 


) 


Fig. 4.1_12. Textul funcției next_Jap( -cazul dispecerizării prin rotație. 


Funcţia init_lapQ 
Această funcţie are rolul de a asigura iniţializarea listei, prin 
înscrierea valorii MAX TSK în toate elementele tabloului prin 


care ea este implementată. 


Textul funcției inir_lapQ va fi, deci, următorul: 


void init_lap (void) | 
uschar i; 
for (i=0; i<=MAX_TSK; i++){ 
_laplil=MAX_TSK; 


) 


1 
2 
3 
4 
5 
6 


Fig. 4.1_13. Textul funcției ini/_lap() -cazul dispecerizării prin rotaţie. i 


O analiză, fie şi doar sumară, a celor patru funcții prezentate 
mai sus conduce la concluzia că toate au implementări 
eficiente, atât în privința timpului procesor pe care îl necesită 
pentru rulare, cât şi în ceea ce priveşte memoria pe care o | 
ocupă / folosesc. i 
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Se poate subînțelege că, pe parcursul rulării aplicaţiilor, cea 
mai frecvent apelată dintre funcțiile în discuţie este, absolut 
detaşat, funcția nexr_lap(; iar codul corespunzător ei, în mod 
evident, este redus la doar câteva instrucții maşină. 


Pentru delectare, să facem, acum, o descindere în concret şi 
să urmărim, în figura 4.1 14, evoluţia listei de aşteptare la 
procesor de la situația din figura 4.1_1, până la vidarea ei de 
taskuri propriu-zise (taskuri propriu-zise = altele decât taskul 
de fond), în ipoteza că lucrurile decurg astfel: 


1. se inserează în lista de aşteptare la procesor taskul 03 

se produce un proces de comutare 

se elimină din lista de aşteptare la procesor, pe rând, 
taskurile: 06-01, 02, 04, 07 şi 03, succedând fiecare 
eliminare, eu excepția penultimei, de câte un proces de 
comutare; eliminarea penultimă -evident: cea care 
vizează taskul 7- se succede de două procese de comutare 
consecutive 


9 


06 09 04 -]:07:1.07.] * 
00 01 02 03 04 05 06 07 08 09 10 


j inserare 03 
v 
06 01:1-09 04 ROT ROT] * 
00 01 02 03 04 05 06 07 08 09 10, 
comutare 
06 |. 01.].09 04: |03 071.03] * 


00 01 02 03 04 05 06 07 08 09 10 


eliminare 06 


04] Torio 03 VARE 
00 01 02 03 04 05 06 07 08 09 10 
comutare 
04 or Foo 03 0701] + 


00 01 02 03 04 05 06 07 08 09 10 


Fig. 4.1_14. Exemplu de evoluţie a listei de așteptare la procesor, 
în cazul dispecerizării prin rotaţie. 
-partea I- 
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sloninare Ol i . i Dispecerizarea prin rotație este satisfăcătoare pentru 
v i - ! aplicațiile în care se solicită sau cel puţin este acceptabilă 
04:|.09 03 07 1:03 i £ ; tratarea tuturor taskurilor în mod echidistant la acordarea 
00 0l 02 03 04 05 06 07 08 09 10 i . i procesorului [20]. 
coniuiape i i i În domeniul informaticii industriale, în general, o astfel de 
Ja oo 03 or Toal» i — į tratare poate îi admisă cel mult la nivelul unui subset din 
E r: j i r : ansamblul taskurilor care definesc o aplicație. Se impune, de 
00 01 02 03 04 05 06 07 08 09 107 i £ ! regulă, în aplicaţiile din acest domeniu, ca unele taskuri să fie 
eliminare 04 i i i tratate cu prioritate mai mare decât altele, având posibilitatea să 
IC 03 9703 i i ; obțină preferențial procesorul şi, de asemenea, să-l 
i i |  monopolizeze cât timp au nevoie de cl, în detrimentul altora. 
00 01 02 03 04 05 06 07 08 09 10 i ; | Ori, dispecerizarea prin rotaţie nu face posibil acest lucru. 
comutare i i H 
09 03 0707]: i i i 
00 01 02 03 04 05 06 07 08 09 10 i ; i : sg 
eliminare 07 i | i a ÎNTR EBĂRI: 
Ji 09 03 [09] i | | n za 
00 01 02 03 04 05 06 07 08 09 10 i | i 
comutare i i: i 
y — ! j i ; Care suni an în care. 
je RORA | 03|03]* | | i dispecerizare prin rotație? 
00 01 02 03 04 05 06 07 08 09 10 | f | 3). Precizați rolul funcției init_lapọ. 
comutare i i i 4). Descrieţi acțiunile funcției i init lap). 
— n E 9303] + i i 5). Daţi o implementare C pentru. functia init lup) 
o0 OI o2 o3 04 05 06 07 08 09 10- | i 6). Precizaţi rolul funcţiei ins lapQ. 
aere | i 47). Descrieți acțiunile funcției ins. lapQ). ; 
PORAS i ; i 8). Daţi o implementare C pentru funcția ins lup). 
091.09 i / 4 9). Precizați rolul funcției elim. lapQ. 
00 01 02 03 04 05 06 07 08 09 10 i | 10). Deserieţi actiunile funcției eliiu._lap0). i 
omae i | 11). Dati o implementare C pentru functia elim._lapQ. 
Y i i 12). Precizaţi rolul funcţiei next lapQ........ 
0909]: ; 13). Deserieţi acțiunile funcției next_lapỌ. 
00 01 02 03 04 05 06 07 08 09 10 i 14). Daţi o implementare C pentru functia next lap(). 
Dea H 15). Prin ce se caracterizează aplicațiile în care este 
Fig, 4.1_14. ERA or Ma Sa d ra la procesor, i recomandată dispecerizarea prin rotaţie? 


-partea a l-a- 

Observație: i 

Semnul "*" marchează sesiunile în care taskurile aflate în 
postura de coadă de listă sunt ajunse efectiv în rulare. 
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- dacă situaţia din figură ar suferi o modificare, constând 
în inserarea taskului 5 în lista de aşteptare la procesor, 
pe nivelul de prioritate 0, atunci proximul proces de 
comutare ar introduce în rulare taskul 5, în timp ce 
taskul 3 ar rămâne în starea gata, așteptând să devină 
din nou cap de listă, pentru a-şi continua rularea. 


4.2. Dispecerizarea prin prioritizare 


Principiul dispecerizării prin prioritizare este, ca şi cel al 
dispecerizării prin rotație, simplu. El presupune că fiecare task 
are asociată, de la crearea sa, o anumită prioritate. Aceasta este 
folosită pentru ordonarea listei de aşteptare la procesor, astfel 
încât taskul cu cea mai puternică prioritate să fie în capul listei, 
taskul cu cea mai slabă prioritate -în coada listei, iar celelalte - 


intrare taskuri devenite rulabile 


E 
corespunzător. 

f 

În cadrul procesului de comutare, dispecerul introduce în f crt 

rulare taskul aflat în capul listei de aşteptare la procesor, deci la a 
taskul cu cea mai puternică prioritate. Evident, dacă în S— | intrare task 
intervalul de timp ce succede unei comutări nici o întrerupere prioritate 0 
fizică (care ar putea fi chiar cea care provoacă procesul de R—— | intrare task 
comutare) şi nici o acţiune a taskului în rulare nu determină ARE prioritate 1 
introducerea în lista de așteptare la procesor a unui nou task, pa vă | intrare task 
care prin prioritatea pe care o are să devină cap de listă, atunci devenite] prioritate 2 
următorul proces de comutare va asigura încă o repriză de | nerulabild a —— 
rulare. aceluiaşi task, care a beneficiat de procesor şi în ! PE intrare (ale 
“intervalul respectiv. Bineînţeles, dacă nu cumva taskul în cauză į prioritate 3 
se autoexclude din lista taskurilor. rulabile, încheindu-și į *—— |intrare task 
activitatea sau blocându-se, dintr-un motiv sau altul. Dacă į prioritate 4 
acest fapt, are loc, cum el atrage după sine, inevitabil, i Intrare task 


ajungerea unui alt task în capul listei, se va produce intrarea în prioritate 5 


rulare a acelui alt task. 


sensul slăbirii Y 
priorităților 


Modelul variantei este reprezentat în figura 4.2_1. 
În situația concretă surprinsă de mo del, se remarcă Fig. 4.2_1. Modelul dispecerizării prin prioritizare. 
următoarele: 

- nivelele de prioritate 0 şi 3 sunt neocupate; 

- taskul cu cea mai puternică prioritate aflat în lista de 
aşteptare la procesor este taskul 3; el nu aşteaptă, de 
fapt, la procesor, ci este efectiv în rulare; 

- un proces de comutare desfăşurat în situația din figură 
asigură încă o repriză de rulare pentru taskul 3; 

- dacă situația din figură ar suferi o modificare constând 
în eliminarea taskului 3 din lista de aşteptare la 
procesor, atunci taskul 7 ar fi cel introdus în rulare. 


Realizarea dispecerizării prin rotație necesită gestionarea 
unei liste circulare de întregi foarte scurți -altfel spus: de tipul 
caracter-, reprezentând indexurile taskurilor rulabile, adică 
indexurile taskurilor aflate în starea gara, ordonată după 
priorități. Un nod al unei asemenea liste va conține, pe lângă 
indexul unui task şi pointerul către următorul nod, şi prioritatea 
taskului asociat nodului; aşa cum se evidențiază în figura 
4.2_2. 
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m: 


d: — 
NE n 
e) b CEREA 
prima poziţie Ă s 0. 
(cap listă) 3 = - 

} d 


a>b>ctc>d E o. 
ultima poziţie 


y7 TAFE $ 
sensul de slăbire a priorităților {coadă listă) 


Fig. 4.2_2. Reprezentarea listei de aşteptare la procesor 
bazată pe priorități. 


În această figură, s-au folosit notaţiile: 
- m,n, 0, p: pentru indexurile taskurilor aflate în listă; 
a, b, c, d: pentru prioritățile taskurilor aflate în listă 


Gestionarea unei asemenea liste comportă implementarea a 
patru funcţii, cele clasice în operarea cu liste: 


void ins_lap(uschar ind _tsk) 
/* inserează în lap taskul cu indexul ind tsk */ 


void elim_lap(usshort ind_tsk) 
/* elimină din /ap taskul cu indexul ind tsk */ 


uschar next_lap(void) 
determină și returnează indexul taskului aflat în capul /ap * 


void init_lap(void) 
/* iniţializează - lista de așteptare la procesor */ 


Fig. 4.2_3. Funcţiile de gestionare a listei de aşteptare la procesor 
-cazul dispecerizării prin prioritizare. 
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Remarcăm faptul că, privite din exterior, aceste funcţii sunt 
identice cu cele relative la gestionarea listelor circulare. În 
realitate, desigur, ele vor diferi substanţial de corepondentele 
lor de la dispecerizarea prin rotaţie. 

Asigurând, în permanență, ordonarea listei în sensul slăbirii 
priorităților, se permite funcţiei nexr_/ap() să determine, într-un 
timp redus la minimum, taskul cel mai prioritar la un moment, 
el aflându-se, întotdeauna, în capul listei; în plus, acest timp 
devine şi independent de prioritatea taskului în cauză. Desigur, 
o funcţie de inserare care respectă criteriul de ordonare a listei 
va fi mai complicată şi, implicit, mai mare consumatoare de 
timp decât una care efectuează inserarea într-o poziție 
prestabilită. Dar operația de inserare este incomparabil mai rar 
executată decât operaţia de determinare a taskului cel mai 
prioritar, aceasta intervenind în fiecare sesiune de lucru a 
dispecerului. 


Implementarea unei liste ordonată după priorităţi se poate 
face tot cu ajutorul unui tablou, dacă numărul maxim al 
taskurilor pe care le controlează executivul este cunoscut. Dacă 
acest număr este MAX TSK, atunci tabloul va avea 
MAX _TSK=-1 elemente. 


Elementul cu indicele MAX_7SK va conţine prioritatea celui 
mai prioritar task aflat în listă la un moment. 


Indicii 0...MAX_TSK-] ai elementelor tabloului se pun în 
corespondență biunivocă cu prioritățile taskurilor. Elementele 
tabloului corespunzătoare acestor indici primesc ca valori 
indexurile taskurilor; dacă un nivel de prioritate este neocupat, 
valoarea elementului cu indicele egal cu prioritatea nivelului 
respectiv va fi MAX_7SK. 


Presupunând MAX_TSK = 10 şi că în lista de aşteptare la 
procesor se află taskurile: 
O -cu prioritatea 3, 
1 -cu prioritatea 2, 
4 -cu prioritatea 6, 


tabloul se va prezenta aşa cum se arată în figura 4.2_4. 
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01-00 104 ; 02 
00 01 02 03 04 05 06 07 08 09 10 
Fig. 4.2_4. O ipostază a tabloului 
corespunzător listei de așteptare la procesor, 
în cazul dispecerizării prin prioritizare. 


Vom folosi şi de data aceasta numele _/ap pentru variabila 
tablou prin care implementăm lista de așteptare la procesor și îi 
asigurăm statutul de variabilă globală, cu locare statică, 
declarând-o în afara oricăror acolade (a se citi: oricărui bloc). 


Să abordăm, în continuare, mecanismul de lucru al celor 
patru funcţii de gestionare a listei. 


Funcţia ins_lapQ 


Această funcție va trebui: 


1. să înscrie valoarea argumentului ind_tsk în elementul 
tabloului _/ap// cu indicele egal cu prioritatea taskului 
de inserat, prioritate aflată din câmpul prior al structurii 
CONTLOG de indice ind _tsk din tabloul _contlog// 

2. să compare prioritatea taskului de inserat cu valoarea 
înscrisă în elementul de indice MAX_7SK al tabloului 
_lap[] şi dacă prioritatea este mai mică decât această 
valoare, atunci să o înscrie în locul ei în acest element, 
întrucât un astfel de rezultat semnifică faptul că taskul 
nou introdus în listă are, în cadrul acesteia, cea mai 
puternică prioritate. 


Rezultă următorul text pentru funcția ins_/apQ: 


void ins_lap(uschar ind_tsk) ( 
_Aapl[_contlog[ind_ tsk] .prior]=ind_tsk; 
i£ (_contlogl[ind_tsk] .prior<_lap [MAX_TSK]) î 


_lap[MAX_TSK]=_contlog[ind_tsk] .prior; 
} 


Fig. 4.2_5. Textul funcţiei ins_/ap -cazul dispecerizării prin prioritizare. 
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Funcţia ejim_lap() 


Această funcţie va trebui să înscrie în elementul tabloului 
_lap[] cu indicele dat de prioritatea taskului de eliminat 
valoarea MAX_TSK, pentru a marca drept neocupat nivelul de 
prioritate căruia respectivul element îi corespunde. Evident, ca 
şi mai sus, prioritatea taskului de eliminat este aflată din 
câmpul prior al structurii CONTLOG de indice ind isk din 
tabloul _contlog/]. 


De asemenea, funcţia are sarcina de a verifica dacă nu 
cumva taskul exclus din listă era cel mai prioritar. În caz 
afirmativ, se impune determinarea succesorului taskului exclus 
şi promovarea acestui succesor în capul listei, prin înscrierea 
priorităţi sale în elementul de indice MAX_TSK. 


Rezultă următorul text pentru funcția e/im_lap(): 


1 void elim_ lap(uschar ind _tsk) 4 
2 uschar j; 
3  _lap[_contlogiind tsk].prior]=MAX TSK; 
4 if (_lap [MAX_TSK]== 
_contloglind_tsk] .prior) { 


5 3=0; 
6 while (j<MAX_TSK) ££ (_lap [1 ]==MAX_TSK) ( 
7 jtt; 
8 } 
9 _lap [MAX_TSK]=j; 
10 } 


Fig. 4.2_6. Textul funcției e/in_lapQ -cazul dispecerizării prin prioritizare. 
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Funcţia nexz_lap( 


Această funcţie are sarcina de a indica taskul aflat în capul 
listei. Pentru a și-o achita, ea va identifica acest task, citindu-i 
indexul din elementul lui lap// cu indicele înscris în 
lap[MAX_TSK]. 


~ 
Desigur, indexul taskului din capul listei va trebui să fie şi 


returnat, pentru ca el să poată fi folosit de apelant. 


Textul funcției nexr_/ap( este următorul: 


uschar next _lap (void) { 
return(_lap [_lap [MAX_TSK]]); 


Ww N H 


} 


Fig. 4.2_7. Textul funcției urm _lap() -cazul dispecerizării prin prioritizare. 


Funcția init_lap() 


Această funcție va asigura inițializarea listei ("vidarea" 
acesteia), prin înscrierea valorii MAX_TSK în toate elementele 
tabloului /ap//. 


Textul funcției init_lap0 este următorul: 


void init_lap (void) | 
uschar i; 
for (i=0;i<=MAX_TSK;i++){ 


_lap[i]=MAX_TSK; 


Fig. 4.2_8. Textul funcţiei ini?_/ap() -cazul dispecerizării prin prioritizare. 
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Analizând cele patru funcții, ajungem la aceeaşi concluzie ca 
și în cazul dispecerizării prin rotaţie, în ceea ce priveşte timpul 
procesor pe care ele îl consumă în rulare și memoria ocupată / 
folosită: ambii aceşti indicatori au valori foarte bune. 


Dispecerizarea pe bază de priorităţi este satisfăcătoare pentru 
o gamă largă de aplicații din domeniul informaticii industriale. 
Totuşi, tratarea obligatoriu discriminatorie pe care ea o impune 
pentru toate taskurile, reprezintă o limitare în ceea ce priveşte 
versatilitatea ei. 


ÎNTREBĂRI: 


1): Prin. ce. se. caracterizează ar 
prioritizare? 

2). Care: sunt freie în eare or stă 

3). 

4). nai erile pasta init flap 

5). Dați o implementare C pentru. Juncjia zii i lapỌ. 

6). Precizati rolul funcției ins. lap): = = 

7): Descrieti acțiunile funcţiei ins. lapQ. . 

$): Daţi o implementare C pentru funcţia îns 1ap0. 

9). Precizaţi rolul funcției elim: lapỌ: 

10). Descrieți acțiunile funcției elim lapQ. 

11): Daţi o implementare C pentru funcția elinlapQ: 

12). Precizaţi rolul funcției next. lap(Q). 

13). Descrieţi acțiunile funcţiei next. lapQ. 

14). Dati o implementare C pentru functia next lapỌ: 

15). Prin ce se caracterizează aplicațiile” în. care. este 

: recomandată dispecerizarea prin prioritizaie? 
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4.3. Dispecerizarea prin prioritizare 
şi rotaţie 


Dispecerizarea prin prioritizare și rotație reprezintă, după 
cum denumirea ei o și sugerează, de altfel, o combinaţie 
cumulatoare de avantaje între dispecerizarea prin prioritizare şi 
dispecerizarea prin rotaţie. 


| Dispecerizarea prin prioritizare şi rotaţie se caracterizează 

| prin faptul că admite ca o prioritate oarecare să fie asociată 

li simultan mai multor taskuri, taskurile cu aceeași prioritate fiind 
tratate prin rotație. 


În consecință, lista de așteptare la procesor, în care sunt 
înscrise, şi de această dată, taskurile rulabile va consta, de fapt, 
într-o înlânţuire de liste circulare, fiecare dintre acestea 
corespunzând taskurilor de o anumită prioritate; ordinea de 
succedere a listelor circulare va fi cea de slăbire a priorităților 
taskurilor incluse în ele. 


Modelul acestei variante de dispecerizare se poate 
reprezenta, considerând o situație concretă, aşa cum se arată în 
figura 4.3_l. 


În situaţia surprinsă în model, se remarcă următoarele: 


- lista de aşteptare la procesor cuprinde zece liste circulare, 
corespunzătoare celor zece nivele de prioritate aflate la 
dispoziţia  taskurilor 

- listele de prioritate 0, 2, 3, ..., 7 sunt vide, lista de 
prioritate 1 cuprinde taskurile 01, 08, 02 şi 05 -cu taskul 
05 aflat în rulare și figurând drept coadă de listă-, lista de 
prioritate 8 cuprinde taskurile 4 şi 7, iar lista de prioritate 
9 cuprinde taskul 09, considerat, şi de data aceasta, cu 
statut de task de fond 

- în ipoteza conservării conţinutului listei de aşteptare la 
procesor, prin procese de comutare succesive, vor intra 
în rulare taskurile 01, 08, 02, apoi din nou 05, 01 
ş.a.m.d. 
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i taskul 04, trecând, implicit, cu această ocazie, pe ultima 


- taskurile de pe nivelul de prioritate 8 pot intra în rulare 
abia după vidarea listei de prioritate 1, în ipoteza că, 
între timp, nici un task rulabil nu ajunge inserat în 
vreuna din listele 0, 2, ..., 7, evident mai prioritare decât 
lista 8 

- presupunând că la un moment cea mai prioritară listă 
nevidă devine lista 8, va intra în rulare mai întâi 


poziţie a listei din care face parte (lista 8), apoi tasku 
07 ş.a.m.d. 

- taskul 09 va accede la procesor şi de data aceasta, doar 
dacă nici un alt task nu este rulabil 


listă circulară -prioritatea 0 


e taskur dé priori TOritate 0 


listă circulară -prioritatea N 


W 


intrare taskuri de prioritate | 
listă circulară -prioritatea 2 
ieşire 
taskurj 


devenite 
nernlabile i x p 
i intrare taskuri de prioritate 2 - < 
listă circulară -prioritatea 8 i 
< 4 J- -7 je o H 
A 
a 


intrare taskuri de prioritate 8 
listă circulară -prioritatea 9 


intrare taskuri de prioritate 9 


intrare taskuri 
devenite rulabile 


Fig, 4.3_1. Modelul dispecerizării prin prioritizare şi rotație. 
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Se poate înțelege din cele de mai sus că, dacă toate taskurile 
din sistem au aceeași prioritate, atunci modelul se comportă ca 
şi cel de dispecerizare prin rotație; în schimb, dacă fiecare 
dintre taskuri are o altă prioritate, atunci modelul se comportă 
ca şi cel de dispecerizare prin prioritizare. Intre aceste două 
extreme, o multitudine de combinaţii este posibilă. 


Realizarea dispecerizării prin prioritizare şi rotaţie necesită 
gestionarea unei înlănțuiri de liste circulare având asociate 
priorităţi, înlănţuire în care listele se succed în sensul slăbirii 
priorităților. O asemenea înlănțuire de liste, ca şi listele însele, 
pot fi implementate cu ajutorul a două tablouri corelate: un 
tablou al taskurilor și un tablou al priorităților [20]. 


Tabloul taskurilor implementează listele circulare după 
regulile enunțate cu ocazia discutării dispecerizării prin 
rotație. Un element al tabloului, împreună cu indicele său, 
reprezintă un nod al unei liste. Indicele va avea semnificația de 
index al taskului aferent nodului, iar elementul va avea ca 
valoare indexul succesorului acestui task. Cum se consideră, în 
continuare, că în sistem sunt MAX TSK taskuri, tabloul 
taskurilor va avea MAX TSK elemente, cu indicii 
0..MAX_TSK-1. Valoarea elementelor corespunzătoare 
taskurilor neprinse în nici o listă va fi MAX_7SK. 


Tabloul priorităţilor va avea MAX_7SK+/ elemente, cu 
indicii 0..:MAX_TSK. Indicii 0...MAX_TSK-I se pun în 
corespondență biunivocă cu prioritățile pe care le pot avea 
taskurile. Elementele de tablou cu aceşti indici primesc ca 
valori  indexurile  taskurilor aflate în coada listelor 
corespunzătoare priorităţilor respective. La fiecare schimbare a 
cozii unei liste, valoarea elementului asociat ei va fi actualizată. 
Dacă o listă de o anumită prioritate este vidă, valoarea 
elementului cu indicele egal cu respectiva prioritate va fi 
MAX TSK. 


Elementul de indice MAX_TSK are un rol aparte. Valoarea 
sa indică cel mai puternic nivel de prioritate a cărui listă 
circulară este nevidă. La limită, când nici un task propriu-zis 
nu este rulabil, în acest element va fi înscrisă valoarea 
MAX_TSK-1, corespunzătoare priorităţi taskului de fond. 
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Notând cu _/ap_7/7 tabloul taskurilor şi cu _/ap_p[] tabloul 
priorităților, rezultă, evident, că valoarea expresiei: 


_lap pl_lap plMAX_TSK]] 
repezintă indexul taskului din coada listei nevide de cea mai 
puternică prioritate (mai puţin în regimurile tranzitorii, acesta 


este, evident, taskul aflat în rulare), iar cea a expresici: 


lap t[_lap pl_lap p[MAX_TSK]]] 


reprezintă indexul taskului din capul listei nevide de cea mai 


puternică prioritate. i 
pa saca 


Presupunând MAX_TSK=70, pentru situația din figura 
4.3_1, tablourile _/ap 1/7 şi _lap p[] vor arăta astfel: 


MAX_TSK-1 


[osos [ozon] [oa 102 T09] 


00 01 02 03 04 05 06 07 08 09 


_lap_t 
MAX_TSK 
[05 cai] [07 foo For] 
00 01 02 03 04 05 06 07 08 09 10 
_lap_p 


Fig. 4.3_2. Tablourile lap _t/] ṣi _lap pl] 
corespunzătoare situației din figura 4.3_1. 


Şi de această dată, gestionarea listei de aşteptare la procesor, 


întruchipată de cele două tablouri, comportă, aşa cum se arată 
în figura 4.3_3, implementarea celor patru funcţii clasice. 


83 


CAP. 4. DISPECERIZAREA TASKURILOR 


void ins_lap(uischar ind_Isk) 
/* inserează în Jap taskul cu indexul ind_tsk */ 


void elim_lap(usshort ind_1sk) 
/* elimină din lap taskul cu indexul ind tsk */ 


uschar next_lap(void) 
determină şi returnează indexul taskului aflat în capul /ap 


void init_lap(void) 
/* iniţializează lista de aşteptare la procesor =; 


Fig. 4.3_3. Funcţiile de gestionare a listei de aşteptare la procesor 
-cazul  dispecerizării prin prioritizare şi rotaţie. 


Să intrăm, acum, în câteva detalii privind aceste funcții. 


S 
Funcţia ins_lap 


Această funcţie. va. trebui, în primul rând, să verifice dacă 
lista circulară asupra căreia trebuie să opereze este vidă sau nu. 


În câzul în care do canta listă este vidă, inserarea În ea 4 a 


rea în elementul de “indice ind _tsk “in tabloul 
> r arrana O pt E 

taskurilor a valorii ind fsk, întrucât taskul în cauză îşi va 

succede în respectiva listă sie însuşi, reprezentând, deopotrivă, 

capul şi coada ei. Aşa stând lucrurile în acest caz, valoarea 


prin  înscri 


argumentului id_/sk se va înscric, de asemenea, de astă dată 
cu semnificaţia de coadă de listă, în elementul din tabloul 
priorităţilor al cărui indice este egal cu prioritatea taskului de 
inserat, prioritate aflată din câmpul prior al structurii 
CONTLOG de indice ind tsk din tabloul _contlog/]. 
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În cazul în care lista nu este vidă, inserarea în ea a taskului 
cu indexul precizat prin argumentul ind /sk presupune 
instalarea acestui-task în capul liştei corespunizătoriie. priorități 
indicată de câmpul prior al structurii CONTLOG de indice 
ind tsk din tabloul _contlog{]. Acest lucru se asigură prin 
copierea în elementul din tabloul taskurilor cu indicele ind tsk 
a indexului taskului surprins în postura de cap de listă, index 
aflat în elementul din același tablou corespunzător cozii listei în 
cauză, urmată de înscrierea valorii ind _ģsk în acest element 
corespunzător cozii. Se reamintește că indicele elementului din 
tabloul taskurilor asociat cozii unei liste de o anumită 
prioritate se găseşte în tabloul priorităților, în elementul aferent 
priorității respective. 


Revenim la cazul în care lista asupra căreia trebuie să 
opereze funcţia ins_lap() este găsită vidă, pentru a adăuga că,- 
în acest caz, se impune, suplimentar, compararea priorității 
taskului nou inserat cu valoarea înscrisă în elementul de indice 
MAX_TSK din tabloul priorităților (valoare care reprezintă cea 
mai puternică prioritate căreia îi corespunde o listă circulară 
nevidă) şi, dacă este nevoie, înlocuirea acestei valori cu 
prioritatea taskului nou inserat. 


Rezultă, aşadar, pentru funcția ins_Jap(), textul din figura 
4.3_3 


void ins_lap(uschar ind_tsk) ţ 
uschar k; 
uschar i; 
k=_contlog[ind_tsk].prior; 
if (_lap_p[k]==MAX_TSK) { 
_lap_tlind_tsk]=ind_tsk; 
z182 [k]=ind tak 
=0; 
ahile ((_lap_p[i]==MAX_TSK) && (î<k)) î 
itt; 


} 
if (i==k) { 
_lap_p[MAX_TSK] =k; 

} 
} 
16 else{ 
17 _lap_t[ind tsk]=_lap_t[_lap_p[Ik]]; 
_lap_t[_lap_p[k]]=ind_tsk; 


ins_lap() 
-cazul dispecerizării prin prioritizare şi rotație. 
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Funcţia elim_lapO 


Această funâţie va trebui, în primul rând, să efectueze 
identificarea în tabloul taskurilor a elementului care conţine 
indexul taskului de eliminat, index precizat prin argumentul 


ind _tsk. 


Procesul de căutare prin care se realizează „această 
identificare se poate efectua analizând succesiv conținuturile 
elementelor tabloului respectiv, de exemplu, de la primul către 
ultimul, aşa cum s-a procedat la funcția elim_lap() din cazul 
dispecerizării prin rotaţie. 

O soluție mai eficientă, în ceea ce priveşte timpul necesar 
găsirii elementului căutat, se poate obţine prin limitarea căutării 
doar la nivelul subsetului de elemente ale tabloului taskurilor, 
implicate în implementarea listei circulare în care trebuie 
să figureze taskul de eliminat. Dispunându-se, din câmpul 
prior al structurii CONTLOG de indice ind_1sk din tabloul 

contlos[], de prioritatea taskului, prin citirea valorii înscrise 
în elementul din tabloul priorităţilor cu indicele egal cu această 
prioritate, se obţine indexul taskului aflat în coada listei în 
cauză. Cu elementul din tabloul taskurilor având indicele egal 
cu acest index, se poate începe procesul de căutare, ținând 
seamă că, valoarea înscrisă în el, ca de altfel și în celelalte cu 
care el este înlănțuit, reprezintă fic indexul taskului de eliminat, 
fie indicele elementului următor din _lap_//7 în care acest 
index s-ar putea găsi. 


Odată identificat elementul care conține indexul taskului de 
eliminat, se impune tratarea diferită a cazului în care acest task 
este coadă de listă, de cazul în care el nu este aşa ceva. O 
comparare a valorii argumentului ind_tsk cu valoarea înscrisă 
în elementul din tabloul priorităților cu indicele egal cu 
prioritatea taskului de eliminat pune în evidență cazul în speță: 
dacă cele două valori sunt identice, taskul de eliminat este 
coadă de listă, altfel, nu. 


În primul caz, dacă indicele elementului din tabloul 
taskurilor în care a fost găsit indexul taskului de eliminat este 
egal cu acest index -adică: cu valoarea înscrisă în acest 
element-, înseamnă că acest task era unicul din listă și, drept 
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urmare, prin eliminarea lui, lista rămâne vidă. Eliminarea se 
efectuează, în această situație, prin înscrierea valorii MAX_7SK 
atât în elementul din tabloul taskurilor care a conținut indexul 
taskului de eliminat, cât şi în elementul din tabloul priorităţilor, 
corespunzător priorității acestui task, Pe lângă eliminare, în 
acest caz se impune să se verifice dacă nu cumva această 
prioritate era cea mai puternică dintre cele care aveau asociate 
liste circulare nevide. 


x Verificarea se efectuează prin compararea priorității taskului 
de eliminat cu valoarea înscrisă în elementul de indice 
MAĂ_TSK din tabloul priorităţilor. Egalitatea semnifică faptul 
că prioritatea taskului eliminat era cea mai puternică şi conduce 
la necesitatea actualizării valorii elementului de indice 
MAX _TSK. Actualizarea se efectucază prin înscrierea în 
elementul în discuţie a valorii celui mai mic indice din tabloul 
priorităţilor, care are asociat un element ce conține o valoare 
diferită de MAX_TSK. 


Tot în acest prim caz, dacă indicele elementului din tabloul 
taskurilor în care a fost găsit indexul taskului de eliminat nu 
este egal cu acest index, înseamnă că acest task nu este unicul 
în listă. Eliminarea presupune, în această situație, două acţiuni. 
Prima: instalarea în coada listei a predecesorului taskului de 
eliminat, prin înscrierea indexului său, egal cu indicele 
elementului din tabloul taskurilor în care a fost găsit indexul 
taskului de eliminat, în elementul din tabloul priorităţilor cu 
indicele egal cu prioritatea taskului de eliminat. A doua acţiune 
constă în copierea în elementul din tabloul taskurilor în care a 
fost găsit indexul taskului de eliminat a indexului 
succesorului acestui task, aflat în acest tablou în elementul de 
indice ind_tsk. 


În al doilea caz, caracterizat prin faptul că taskul de eliminat 
nu este coadă de listă, eliminarea se efectuează prin simpla 
copiere în elementul din tabloul taskurilor în care a fost găsit 
indexul taskului de eliminat a indexului succesorului acestui 
task, aflat, cum s-a precizat mai sus, în elementul acestui tablou 
cu indicele ind tsk. 
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Textul funcţiei elim_lapQ, scris în conformitate cu cele de 
mai sus, face obiectul figurii 4.3_4. Pentru o mai uşoară 
înţelegere a sa, acțiunile pe care el le implementează se redau 


organigramic în figura 4.3_5. 


uschar k; 

uschar j; 

k=_contlog [ind _tsk] .prior; 

3= _lap plk]; 

while ((_lap_E[3] Izind_tsk) && 

(_lap_t[5l!= lap_plk])) i 

j=_lap_t[j]; 

) 

if (_lap t[il>>=ind_ tsk) { 


if(ind_tsk==_lap_p[k]){ // ind_tsk= coadă | 
if (3==_tap_tL3))4// ind_tsk = coadă şi singur 


_lap_ t[j]=MAX_TSK; 
_lap_p[k1=MAX_TSK; 
if (k==_Lap_pIMAX_TSK] ) ( 
j=k; 
do{ 
jtt; 


}while (_lap_p[j]==MAX_TSK) $ 


_lap_p IMAX_TSK]=3 ; 
) 
) 
else{ // ind_tsk = coadă, dar nesingur 
_lap_plk]=j; 
_lap_tljl= _lap_t [ind_tsk] ; 
_lap_t [ina_tsk]=MAX_TSK; 
) 
} 
else{ // ind_tsk != coadă 
_lap_t[j] =_lap_t [ind_tsk] ; 
_lap tI ind_tsk]=MAX_TSK; 


„Fig, 4.3_4. Textul funcţiei elim_lap() 


-cazul dispecerizării prin prioritizare şi rotaţie. 
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momente 


| 
| 


k=_contlog[ind_tsk].prior 


4 
j>_lap_plk] 


“lap_tj]=ind_tS 
&& 


_lap_t[j]!= _lap_pl 


eu 
J- lap tli] 


4 DA 


N-are > 
_lap_[j]=_lap_t[ind_tsk] 


_iap_t[ind_tsk]2MAX_TSK DA 


_lap_tlj) 
_lap_t[ind_tsk]eMAX_TSK 


_lap_plk]=j 


=_lap_t[ind_tsk] 


_lap_Dl>MAX_TSK 
_lap_p[k]= MAX_TSK 


ee 


NU 
_lap_piMAX_TSKy.j 


>t pa le 


Fig. 4.3_5. Organigrama funcţiei e/in:_Jap(), 
în cazul dispecerizării prin prioritizare şi rotație. 
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Menţionăm că, atât în organigramă, cât şi în textul funcţiei, 
s-a asigurat, în plus faţă de cele spuse până aici, identificarea 
situaţiilor când argumentele funcţiei nu corespund celor din 
lista de aşteptare la procesor. În aceste situații, funcția rămâne 
fără nici un rezultat. Bineînţeles, nici o greutate nu ar fi să se 
genereze un mesaj specific acestor situații, dar, în prezentul 
context, s-a considerat că acest lucru este lipsit de interes. 


Funcţia next_lapO 


Această funcţie are sarcina de a determina şi indica 
succesorul taskului aflat în rulare. Acest succesor este tocmai 
taskul aflat curent în capul listei circulare cu cea mai 
puternică prioritate. Indexul său se află înscris în elementul din 
tabloul taskurilor cu indicele dat de valoarea expresiei: 


_lap p[_lap p[MAX_TSK]] 


Totodată, funcția nexr_lap( trebuie să asigure și instalarea în 
coada listei circulare în cauză a acestui task, desemnat ca 
"următorul", înscriindu-i indexul în elementul din tabloul 
priorităților cu indicele aflat în _lap _p[MAX_TSK]. Această 
operaţie este însoțită, implicit, de avansarea în cadrul listei cu o 
poziţie şi a celorlalte taskuri pe care lista le include. 


Textul funcției next_lap() este următorul: 


uschar next_lap (void) { 
_lap_P [_lap_P [MAX_TSK] ]= 


_lap_ti_lap pl_lap_P [MAX _T7SK]]]; 
return (_lap_pl_lap_pIMAX_TSK]]) ; 
} 


Fig. 4.3_6. Textul funcţiei next _lap0) 
-cazul dispecerizării prin prioritizare şi rotație. 
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i 


Funcţia init lapo 


Această funcție are sarcina de a asigura inițializarea listei de 
aşteptare la procesor ("vidarea" acesteia), prin înscrierea 
valorii MAX_TSK în toate elementele tablourilor _/ap_//, 
respectiv _lap p[]. Reamintim, tabloul _lap_t[] are 
MAX- TSK elemente, cu indicii 0...MAX_TSK-1, iar tabloul 
_lap_p[] are MAX_TSK-+1 elemente, cu indicii 0... MAX_TSK. 


Textul funcției iniț_/ap( este prezentat în figura 4.3_7. 


1 void init lap(void) 4 
2 uschar i; 
3 for(i=0;i<MAX_TSK;i++){ 
i 4 _lap_t[il=MAX_TSK; 
| 5 _lap_plil=MAx_TSK; 
i 6 } 
| 7 _lap_pIMAX TSKJ=MAX_ TSK; 
8) 


Fig. 4.3_7. Textul funcţiei ini?_lap() 
-cazul dispecerizării prin prioritizare şi rotație. 


O analiză comparată a celor trei variante de dispecerizare 
prezentate evidențiază superioritatea netă a dispecerizării prin 
prioritizare și rotaţie, în raport cu dispecerizarea doar prin 
rotație, respectiv cu dispecerizarea doar prin prioritizare, în 
ceea ce priveşte versatilitatea. Pe de altă parte, însă, funcțiile de 
gestionare a listelor aferente dispecerizării prin prioritizare şi 
rotaţie, în mod deosebit funcţia efim_lap(), sunt mai complexe 
şi mai mari consumatori de timp procesor, decât funcțiile 
corespondente aferente celorlalte două variante de 
dispecerizare. 


Având în vedere toate aspectele notabile, atât cele pozitive, 
cât şi cele negative, se poate conchide că cea mai avantajoasă 
variantă de dispecerizare este cea prin prioritizare şi rotație. 
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A i INTREBARI: 

Vă 

| : i : 

HE y h i y i e DSRS SA 
| D. Prin ce se caracterizează dispecerizarea prin 
| ju prioritizare şi rotație? 

12): Care sunt Jincțiile. în care. consistă mecanismul 
$ “de dispecerizare prin prioritizare şi rotaţie? 
13). Precizaţi rolul functiei init_lapQ. 


4). Descrieri acțiunile funcţiei init_lapQ. 

5). Dați o implementare C pentru funcfia init flap): 

6). Precizaţi rolul funcției ins. ap. 

7). Descrieţi acțiunile. funcției ins_lap(). 

. Dati o implementare C pentru funcția ins _lapO; 

Pr ecizaţi, rolul funcției elim lapQ): 

nile funcției elim_lapQ. 

entare C pentr: u funcţia elim lup. 
d 


ncţiei u m i_lap0.. 
eniru funcția urm lapQ. 
licațiile în care este 
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o 
E 
E 
I 


-~ REZUMAT 


Se numeşte dispecerizare ansamblul de acțiuni. prin care, 
în cadrul procesului de comutare, se realizează desemnarea 
taskului ce urmează să fie introdus în rulare. 


Criteriile. pe baza cărora dispecerizarea. este efectuată 
sunt relativ. diverse. Cel mai. frecvent. sunt folosite 
dispecerizărea prin rotație, dispecerizai-ea prin. prioritizare, 
je dica ineaca prin prioritizare şi rotație, m combinație 


Dispecerizarea prin rotație. se car acteiizează hr in aceea 
că: în y 
1 ). are la bază o listă de aşteptare Ji procesor. circulară; 

2), dispecerul. care. o. implementează pi ocedează, în 
„fiecare sesiune a sa, în felul a urmă ; i 

e actualizează 
aşteptare. la 


i poziție ı mai în față; 

`o scoate din rulare taskul e găsi în execuție ul ; 

e. introduce în rulare taskul tocmai instalat í în c dä 

listei de aşteptare la procesor: (adică: faskui gäsit 

la începutul sesiunii în capul listei de aşteptare la 
procesor): i | 


=- Dispecerizarea. prin prioritizare se caracterizează prin 
aceea că: 
1). are la bază o. listă de „aşteptare lä; procesor. 
- prioritizată; ; 
2. dispecerul: care o implementează procedează, : în 
fiecare sesiune a să, în felul următor: 
o lasă neschimbată. ordinea taskurilor în lista. de 
“aşteptare la procesor; 
"e scoate din rulare taskul găsit î în execuție; 
"e introduce în rulare tashul găsit în-capul. listei de 
: anleptare la pr OCCSOF: 
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Dispecer izarea prin prior. itizare şi rotajie se 
caracterizează prin aceea că: 
I). are la bază un ansamblu de diste de piară la 
" procesor circulare, fiecare cu o anumită prioritate, 
diferită de a celorlalte; 
2). dispecerul care o implementează procedeaza, în 
fiecare sesiune a să, în felul următor: . 
o aclualizează ordinea taskur ilor îm lista de 
"aşteptare la pr -ocesor. din care face parte taskut: 
găsit în execuţie, trecându-l pe cel din capul listei 
în coadă, iar pe celelalte mutându-le cu o pozitie 
“mai în față; . ii 
"e scoate din rulare taskul găsit în execuție; 
"introduce în rulare taskul tocmai instalat. în coada 
ci de aşteptare la procesor de cea mai 


mecanismul. de dispecerizare 


aşteptare la procesor “y 


ja ins. ;_lap0) 
i /* inserează un task */. 
/ * în lista de aşteptare la procesor */: 


“elim_lapQ) 
- /* elimină un task */ 
/* din lista de aşteptare la procesor ZA 
; -next lap) 
: /* determină taskul */ 
—— pi ceur mează să ape Prodis 4 în rulare E 


Dispecerizarea prin rotație. este recomandată în aplicațiile 
în care laskurile sunt egal. îndrituite să beneficieze de 
procesor : n 
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| 
| 
| 
i 


15). Precizaţi rolul. funcției urm lap): 


d 17). Daji o d mplementare C pentru funcția urm ap). 


Dispeceri izarea „prin pi ioritizare . este recomandată -m 
aplicațiile în care taskurile sunt sensibil diferențiate în privința 
atuurilor pe care le au că să li se acorde procesorul. 


„ Dispecerizarea prin prioritizare şi rotație este recomandată 
în aplicațiile complexe, în care taskurile pot fi împerțite. în 
grupe ierar: hizate, după cr iteriul gradului de îndrituire pentru 
a beneficia de procesor. 


- ÎNTREBĂRI: 


1). Ce se s intelege prin dispecer. rizare! : 
2). Fii -in ce se caracter izează di pec 


prioritzar e? 
4). sia in ce se car ac e 


i Peoi izare?.. 
6). Precizaţi rolul funcţiei init ap, 
7). Descriieţi acțiunile funcției init: lup, 
8): Dați o implementare C pentru funcţia init- lapQ). 

o 9). Precizaţi rolul funcţiei ins -lapO. 

10). Deserieți acțiunile funcției ins. lapQ). 

11). Daţi o implementare C pentru functia ins lapQ. 

12). Precizaţi rolul funcției elim lapo.. 

13). Descrieți acțiunile functiei elim lup, 

14). Dati o implementare C pentru, funcția elini lapQ). 


16). Descrieţi acțiunile, fimncţiei urni 2 lapQ. 


e 
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“i $). Prin ce se caracter izează aplicaţiile i în care este 
recomandată dispecerizarea prin rotație? 
19). Prince se caracterizează aplicațiile î în care este 
"recomandată dispecerizărea prin prioritizare? 
20). Prin ce se caracterizează aplicaţiile î în care este. 
recomandată dispeceri izarea 1 pr in pr ioritizare şi 
i rotație? i 
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5 
STABILIREA PERIOADEI 
DE COMUTARE A TASKURILOR 


Aşa cum s-a arătat deja, într-un sistem în timp real cu 
multitasking are loc un fortaj al procesului de comutare cu un 
ritm fix, ca urmare a întreruperilor fizice provocate de ceasul 
de timp real al sistemului. Pe lângă comutările periodice 
introduse prin acest forțaj, pot apare, sporadic, comutări 
suplimentare, cauzate de alte întreruperi fizice sau de apariţia 
unor situaţii ce le impun (condiţii de blocaj, etc.), în cadrul 
procesului de rulare a taskurilor. 


Această stare de lucruri nu conduce, însă -sau nu trebuie să 
conducă!-, la pierderea identității comutărilor provocate de 
ceasul de timp real. Evident, doar vis-a-vis de acestea se poate 
vorbi despre o perioadă de repetiţie a procesului de comutare. 
În consecință, în cele ce urmează, facem abstracţie de existența 
şi a altor comutări. 


Prin faptul că periodic este forțat procesul de comutare, 
fiecare task primeşte, la intrarea sa în rulare, un cuantum de 
timp la care este limitată rularea sa contiguă. Într-un sistem cu 
dispecerizare prin rotație, de exemplu, după expirarea acestui 
cuantum, un alt task va fi introdus întotdeauna în rulare, taskul 
care l-a precedat urmând să primească din nou procesorul abia 
mai târziu. 


Este de subînţeles că, într-un asemenea sistem, cu cât este 
mai ridicată frecvența de repetare a comutărilor, cu atât, 
într-un interval de timp fixat, își vor avansa activităţile, în 
paralel, mai multe taskuri, ceea ce nu poate fi decât 
mulțumitor. 
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Dar, dacă avem în vedere faptul că la fiecare comutare 
procesorul este acaparat pentru un timp de către dispecer, 
“putem deduce că din durata intervalului avut în vedere, timpul 
cât procesorul este la dispoziția taskurilor va fi cu atât mai 
redus cu cât numărul de comutări din acest interval este mai 
mare. Figura 5_1 evidenţiază 


clar aceste aspecte, punând față în față situaţia în care în 
intervalul de timp T au loc două comutări, cu situația în care, în 
acelaşi interval F au loc trei comutări. 


Timp |Timp dedicat] Timp Timp dedicat! Timp |Timp dedicat 
consumat] rulării  |consumati rulării [consumati rulării 

pentru | unui task | pentru | unuitask | pentru | unui task 
comutare comutare comutare 


iq t — >l- A t—he— A, —>|4 t—|— Arm 
PTT mT cc 
a 


a). 

Timp Timp Timp Timp 
consumat dedicat consumat dedicat 

pentru rulării pentru rulării 
comutare unui task comutare unui task 
+: A A 

Tə 

REG CR R 


b). 
a). Timpul consacrat taskurilor în intervalul [: 3*4; =/- 3% 
b). Timpul consacrat taskurilor în intervalul |: 2*4 = /- 2% 
=> 2 *A43> 3 *Ap 


Fig. 5_1. Cu privire la influenţa frecvenței comutărilor 
asupra timpului procesor consacrat taskurilor. 


Rezultă că stabilirea perioadei de repetiție a comutărilor 
trebuie efectuată astfel încât să se asigure un compromis între 
numărul taskurilor ce au şansa să-şi avanseze în paralel 
activitățile într-un interval fixat şi volumul de timp din acel 
interval consacrat comutărilor. 
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Pentu a se putea exprima cantitativ eficiența cu care un 
sistem multitasking în timp real asigură deservirea unei 
aplicații, se introduce noţiunea de eficacitate de utilizare a 
procesorului, notată cu E, definită prin relaţia [20]: 


E = (79 /7 


respectiv: 


unde: 
T: reprezintă perioada comutărilor 
ft: reprezintă durata procesului de comutare 


De exemplu, pentru 1=100 us, se obţin: 
E=0.9, dacă T= 1.0 ms 
E=0.5, dacă T=0.5 ms 


Se menționează că executivele de timp real dedicate 
domeniului informaticii industriale se caracterizează prin timpi 
de comutare de ordinul 10 us ... 200 us şi perioade de comutare 
de ordinul 100 us... 5000 us, în combinaţii care asigură o 
eficacitate de utilizare a procesorului de 0.8 ... 0.99. 


Este evident că, cu cât eficacitatea de utilizare a 
procesorului este mai scăzută, cu atât timpul în care un task 
îşi exercită atribuţiile, respectiv îşi încheie o sesiune de lucru 
completă, devine mai lung (termenii "cu cât...” , "cu atât..." 
au, desigur, un sens calitativ și nicidecum cantitativ). 
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CAP. 5. STABILIREA PERIOADEI DE COMUTARE ... 


REZUMAT ÎNTREBĂRI: 


1): Ce avantaj prezintă efectuarea comutării. taskurilor: cu 
o frecventă ridicată? 

2): Ce dezavântaj prezintă efectuarea comutării taskuriloi 
cu:0.Jiecvenţă ridicată? 

3). Ce este eficacitatea de utilizare a procesorului? 

4). Ce timpi de: comutare : sunt. caracteristici pentru 
domeniul informaticii industriale? | 

5). Ce perioade. de comutare Sunt. caracter istice pentrul 
domeniul informaticii industriale? : ; 

6). Ce. eficacități de. utilizare: a procesorului sunt) 
caracteristice pentru domeniul informatiċi: industriale? | 


fut-un. sistem multitasking în care. în fiecare sesiune de 
comutare un alt task este introdus în execuție, cu cât este mai 
ridicată Jecvența de. repetare. d comutărilor, cu atât; într-un 
interval de timp fixat, îşi vor avansa activitățile, în pari alel; mai 


multe taskuri. 


E La; fiecare. comutare, procesor: ul este acaparat pentru: un 
Vin de către dispecer. 


"Timpul. cât procesorul va fi, într-un interval: fixat, la 
dispoziţia. Sur ilor este cu atât mai ridical cu cât numărul de 
ări diñ. i repect interval este mai redus. 


comuiă 


Se nume le efi cacitate de utilizare a procesorului raportul 
dintre fracțiunea din perioada. de comutare cât procesorul este 
skurilor şi per ioada de comutare: 


E=(T-0)/T 


E 7 i 
sati, echivalent: ; | i 
i E=1-V/T i : i 

; Pentru domeniul informaticii industriale sunt caracteristici į f i 
timpi de comutare de ordinul 10. 4s...200 ps şi perioade de! i i 
comutare de ordinul 100. s...3000. 15, în. combinaţii. care i î i 
asigură o eficacitate de utilizare a procesorului de 0:8 -.. 0.99. i i 
| | i 
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CAP. 6. CONFLICTE... SOLUȚII... EXCLUDEREA MUTUALĂ 


6 
CONFLICTE POTENȚIALE 
ÎN SISTEMELE MULTITASKING 
ŞI SOLUȚII DE DEPĂȘIRE A LOR. 
EXCLUDEREA MUTUALĂ 


6.1. Noţiunile de resursă critică 
şi secțiune critică 


Prin termenul resursă se desemnează, în general, orice 
entitate de care are nevoie un task pentru a putea fi rulat. 


Natura resurselor poate fi atât materială, cât și logică. 
Resursele de natură materială se numesc resurse materiale, iar 
resursele de natură logică se numesc resurse logice. 


Exemple de resurse materiale sunt: 
- procesorul 
- memoria internă 
- memoriile externe 
- dispozitivele de introducere / extragere 
- ceasul de timp real 
- dispozitivele speciale (procesoare specializate etc.) 


Exemple de resurse logice sunt: 
- variabilele 
- tampoanele de date 
- subrutinele 
- fişierele 
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Resursele accesabiie doar de către un singur task se numesc 
resurse locale. Acestea sunt mai ales de natură logică: 
variabile, tampoane, subrutine, fişiere, dar pot fi şi de natură 
materială: dispozitive de introducere / extragere, etc. 


Resursele accesabile de către cel puţin două taskuri se 
numesc resurse comune. Şi acestea pot fi atât de natură logică: 
variabile, subrutine, tampoane, etc., cât și de natură materială: 
procesor, memorie, dispozitive de introducere / extragere, etc. 


Unele resurse comune pot fi utilizate deodată de către mai 
multe taskuri, altele nu. De exemplu: procesorul nu poate fi 
utilizat la un moment dat decât de un singur task; și s-a studiat 
pe larg, în capitolul 4, modul în care se realizează 
dispecerizarea taskurilor, în scopul alocării procesorului doar 
unuia dintre ele la un moment dat. Alt exemplu: o anumită 
subrutină, care îşi modifică pe parcursul rulării unele date 
proprii, reiniţializându-şi-le doar în final, pentru a se pregăti de 
o nouă rulare, odată apelată de un task nu mai poate fi apelată 
de un altul, până după ce s-a produs rularea ei completă ca 
urmare a primului apel. În fine, încă un exemplu: odată inițiată 
o sesiune de lucru a unui task asupra unei variabile comune, nu 
poate fi declanșată o altă asemenea sesiune de către un alt task, 
asupra aceleiaşi variabile, până după încheierea primei sesiuni. 


Pentru a ilustra ce se poate întâmpla în cazul în care două 
taskuri își efectuează în paralel sesiunile de lucru asupra 
aceleiaşi variabile, să analizăm următorul caz. 


Două taskuri modifică, la fiecare rulare completă a lor, o 
variabilă denumită X, însumându-i valorile a, respectiv b. 
Presupunem, în premizele iniţializării la valoarea ( a acestei 
variabile, că taskul A efectuează, într-un punct al său, 
instrucția: 


X=X+ta; 
iar taskul B, la rându-i, instrucția: 
X=X+b; 
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După efectuarea celor două instrucții de către taskurile A 
respectiv B, indiferent în ce ordine, ar trebui, în mod normal, 
ca variabila X să aibă valoarea: 


X=a+b; 
Dar o instrucție de tipul: 
X=X+u; 


dintr-un limbaj de nivel înalt constă în mai multe instrucții 
maşină -generate de compilator în funcție de setul de instrucții 
al procesorului pentru care el traduce-, corespunzătoare, de 
exemplu, următoarelor operații: 

1). ACUMULATOR (X); 

- transferarea conținutului locației de memorie care 
implementează variabila X într-un registru care 
poate juca rolul de ACUMULATOR; 

2). ACUMULATOR + (ACUMULATOR)+u; 

- adunarea conținutului registrului ACUMULATOR 
cu operandul + (aflat, de exemplu, într-un registru 
oarecare al procesorului) şi depunerea rezultatului în 
registrul ACUMULATOR; 

3). X e (ACUMULATOR); 

- depunerea conținutului registrului 
ACUMULATOR în locația de memorie care 
implementează variabila X. 


Presupunem că taskul A ajunge să execute corespunzător 
instrucției: 


X=X ta; 
doar operația-maşină 1), după care pierde procesorul, fiind 


urmåt în rulare de taskul B, care tocmai este în ipostaza de a 
executa instrucția: 


X=X+b; 
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şi, spre șansa lui, are la dispoziţie timp-procesor suficient 
pentru a executa toate cele trei operaţii -1), 2), 3)- în care 
această instrucţie consistă. Ceva mai târziu, reintră în rulare 
taskul A şi execută operaţiile 2), 3), ce îi rămăseseră în față, și 
apoi alte operaţii care nu prezintă interes aici. 


În concluzie, din punct de vedere cronologic, se va derula 
următoarea secvenţă de operaţii notabile: 


1). ACUMULATOR < (X); 
- operația aparţine  taskului A şi, în urma ei, în 
registrul ACUMULATOR se va găsi valoarea 0; 
2).se pierde procesorul de către taskul A (cu salvarea 
contextului său, deci inclusiv a conținutului registrului 
ACUMULATOR în stiva proprie); 
3), intră în rulare taskul B; 


4). ACUMULATOR & (X); 
- operația aparține taskului B şi, în urma ei, în 
registrul ACUMULATOR se va găsi valoarea 0; 
5). ACUMULATOR < (ACUMULATOR)+b; 
- operaţia aparține taskului B şi, în urma ei, în 
registrul ACUMULATOR se va găsi valoarea b; 
6). X e (ACUMULATOR); 
- operaţia aparține taskului B şi, în urma ei, în locația 
de memorie care implementează variabila X se va 
găsi valoarea b; 


7) a | 
8). se pierde procesorul de către taskul B; 
9). reintră în rulare taskul A (cu refacerea conținutului său, 
deci cu valoarea 0 înscrisă în registrul ACUMULATOR); 
10). ACUMULATOR « (ACUMULA TOR)+aj 
- operația aparține taskului A şi, în urma ei, în 
registrul ACUMULATOR se va găsi valoarea a; 
11). Xe(ACUMULATOR); 
- operația aparține taskului A şi, în urma ei, în 
locaţia de memorie care implementează variabila X, 
se va găsi valoarea a. 
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Se observă că valoarea finală pe care aceste operaţii o 
asigură variabilei A nu este a+b, ci a. Evident dacă sesiunile de 
lucru ale celor două taskuri asupra variabilei X ar fi fost la nivel 
maşină succesive în timp, rezultatul obținut era corect. 


O resursă comună care admite ca doar o sesiune de lucru 
asupra ei să fie în derulare la un moment se numeşte resursă 
critică. 


O resursă comună care admite ca z sesiuni de lucru asupra ei 
să fie în derulare la un moment se numeşte resursă partajabilă 
cun puncte de acces. 


O resursă comună care admite ca oricâte sesiuni de lucru 
asupra ei să fie în derulare la un moment se numeşte resursă 
reentrantă. Evident, resursele reentrante sunt cazuri particulare 
de resurse partajabile, caracterizate prin faptul că n tinde către 
infinit. 


Pentru a avea un exemplu de resursă partajabilă, să ne 
imaginăm că într-un sistem există trei imprimante identice, 
accesibile taskurilor sub formă abstractă, prin intermediul unui 
tabel de alocare a lor. Acest tabel, pe care l-am putea denumi 
IMPRIM_ABSTR, reprezintă o resursă partajabilă cu trei puncte 
de acces. 


O resursă existentă în mai multe exemplare identice, oricare 
dintre ele putând satisface o cerere dată, se numeşte resursă 
banalizată. Cele trei imprimante considerate mai sus reprezintă 
resursa fizică de tip imprimantă, banalizată. 


Un exemplu tipic de resursă reentrantă îl constituie 
subrutinele care își conservă în întregime în timpul rulării 
instrucţiile şi datele cu care operează, admițând în. număr 
nelimitat noi apeluri, înainte ca precedentele să fie în întregime 
onorate. Aceste subrutine se numesc, de altfel, subrutine 
reentrante. 


O porţiune de program prin care se realizează o sesiune de 
lucru asupra unei resurse partajabile se numeşte secțiune de 
partaj. 
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O porţiune de program prin care se realizează o sesiune de 
lucru asupra unei resurse critice se numeşte secțiune critică. 


Se poate înțelege, din definițiile şi exemplele de mai sus, că 
într-un sistem multitasking pot apărea conflicte atunci când cel 
puţin două taskuri necesită una şi aceeaşi resursă critică într-un 
acelaşi interval de timp. Cu alte cuvinte, un conflict apare 
atunci când, în timp ce un task a pătruns într-o secțiune critică a 
sa corespunzătoare unei resurse critice și încă nu a depăşit-o, 
un alt task ajunge pe punctul de a intra în propria-i secțiune 
critică referitoare la aceeaşi resursă. 


Menționăm, de asemenea, că un conflict poate apare atunci 
când, în timp ce 7 taskuri au pătruns în secțiunile lor de partaj 
corespunzătoare unei resurse partajabile cu m puncte de acces, 
fără a le depăşi, un al (7+1) -lea task ajunge pe punctul de a 
intra în propria-i secțiune de partaj referitoare la aceeași 
resursă. 


În practică, apar mult mai frecvent conflictele referitoare la 
resurse critice decât conflictele referitoare la resurse 
partajabile; de altfel, în numeroase aplicaţii, nici nu există 
resurse partajabile. 


1). Ce se înțelege prin resursă? 
2). Ce sunt resursele materiale? 
3). Ce sunt resursele logice? i 
4). Ce se înțelege prin resursă locală? 
5): Ce se înțelese prin resursă comună? 
6). Ce se întelege prin resursă critică? 
7). Ce se întelege prin resursă partajabilă cu "n" puncte 
de acces? ; 
8). Ce se înțelege prin resursă reentrantă? 
9). Ce se înțelege prin resursă banalizată? 
10). Cese înțelese prin secţiune critică? 
11). Ce se întelege prin sectiune de partaj? 
12). În ce situaţii pot apărea conflicte într-un sistem 
multitasking? TEN z 
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6.2. Excluderea mutuală 


Evitarea anomaliilor ce ar rezulta în sistemele multitasking 
în situaţiile în care la un moment ar fi în derulare mai multe 
secțiuni critice referitoare la acecași resursă critică se realizează 
prin împiedicarea apariției acestor situații. Sau, altfel spus, prit 
excluderea de către un task aflat într-o secțiune critică 
referitoare la o resursă, a posibilităţii altor taskuri de a pătrunde 
în secţiuni critice care au ca obiect acceaşi resursă. 


= 


Excluderea de către un task aflat într-o secțiune critică 
referitoare la o resursă a posibilităţii altor taskuri de a pătrunde 
în secţiuni critice care au ca obiect aceeaşi resursă poartă 
denumirea de excludere mutuală. 


Există mai multe mecanisme prin care se poate realiza 
excluderea mutuală. Le vom aborda, în cele ce urmează, pe 
cele care prezintă, din punct de vedere practic, un interes mai 
ridicat [4; 20]. 


6.2.1. Excluderea mutuală prin 
dezactivarea întreruperilor 


Dacă la intrarea într-o secțiune critică se asigură 
dezactivarea tuturor întreruperilor din sistem, eventual mai 
puţin a celor prin tratarea cărora nu se poate ajunge la iniţierea 
unei alte secțiuni critice, referitoare la acceaşi resursă, 
problema excluderii mutuale este gata rezolvată. 


Într-adevăr, prin dezactivarea întreruperilor, este împiedicată 
rechiziționarea procesorului de la taskul ce îşi rulează secțiunca 
critică, făcându-se imposibilă nu numai lansarea unei alte 
secțiuni critice, dar chiar introducerea în rulare a unui alt task, 
prin faptul că mecanismul fizic de iniţiere a procesului de 
comutare este el însuși dezactivat (desigur, presupunând că 
secțiunea critică în derulare nu se autosabotează, conducând, ca 
însăşi, pe căi logice, la un proces de comutare). 
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Este de subînţeles că la încheierea secțiunii critice se impune 
ca întreruperile să fie lăsate aşa cum erau înaintea ei, deci: fie 
activate, fie dezactivate. 


Implementarea excluderii mutuale prin. dezactivarea 
întreruperilor se poate realiza prin delimitarea secțiunilor 
critice cu două macroinstrucții denumite, de exemplu, _/ock(, 
respectiv _unlock(), definite, în mediul de programare pe care 
îl avem în vedere, aşa cum se arată în figura 6.2.1_1. 


define _lock() asmi(pushf; cli;) 


define _unlock () asm(popf;) 


b). 
Fig. 6.2.1_1. Definirea macroinstrucțiilor _lock(), _unlock(). 


Evident,  macroinstruncția _/ock() salvează în stivă 
conţinutul registrului cuvântului de stare a programului şi apoi 
dezactivează întrert uperile, iar macroinstrucţia _unlock() reface, 
prin descărcarea stivei, conținutiil” ăcestiii registru, deci 
inclusiv al fanionului pentru întreruperi, I, asigurând, astfel, ca 
întreruperile să rămână aşa cum au fost găsite de 
macroinstrucția _/ock(): fie activate, fie dezactivate. 


Se poate concluziona, că mecanismul de excludere mutuală 
prin dezactivarea întreruperilor este simplu. El prezintă, însă, 
mai ales în varianta inhibării globale a întreruperilor, neajunsul 
de a implica riscul întârzierii tratării unor întreruperi urgente 
sau chiar al neluării în seamă a unor întreruperi care se succed 
la intervale de timp mici. De aceea, se impune aplicarea acestui 
mecanism cu o atenție aparte, pe cât posibil nedezactivând 
toate întreruperile (se va acționa, în acest sens, la nivelul 
controlerelor de întreruperi) şi numai în cazul secțiunilor critice 
de dimensiuni reduse (mai la obiect: cu timpi de rulare reduşi). 


Se precizează că, în sistemele multiprocesor, mecanismul de 
excludere mutuală prin dezactivarea întreruperilor nu este 
funcţional, dat fiind faptul că fiecare procesor îşi are propriul 
sistem de întreruperi. 
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ÎNTREBĂRI: 


1). În ce consistă mecanismul dezactivării întreruperilor? 

2). Precizaţi rolul macroinstrucției.lock0. 

3). Descrieți acțiunile maci-oinstrucției lock). 

4). Daţi o implementare pentru macroinstrucția lock: 

5). Precizaţi rolul macroinstrucției -unlock); 

6). Descrieţi acțiunile macroinstrucției - unlock(. 

7). Dai o implementare peniru macroinstrucția „unlockQ. 

6). Cum se asigură excluderea mutuală prin mecanismul 
dezactivării. întreruperilon? 

9). Ce avantaje prezintă mecanismul dezactivării 
întreruperilor? i 

10). Ce dezavantaje prezintă mecanismul dezactivärii . 

întreruperilor?. 


6.2.2. Excluderea mutuală prin fanioane 
de excluziune 


Se numeşte fanion de excluziune o variabilă booleană cu 
valoarea inițială "0", asupra căreia se pot efectua două operații: 

- o operaţie indivizibilă de testare şi forțare la "1"; 

- o operaţie de forțare la "0". 


Operația de testare şi forțare la "1" se numește operație TAS, 
ca abreviere de la Test And Ser. 


Operația de forțare la "0" se numeşte operaţie RES, ca 
abreviere de la RESer. 


Evident, în funcție de limbaj, fanionul de excluziune este 
efectiv o variabilă booleană sau o variabilă întreagă tratată 
bivalent. 
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} Se numește fanion de excluziune pasiv un fanion de 
lexctuziune a cărui tratare nu conduce la apelarea dispecerului. 
(Se precizează că atunci când se spune doar "fanion de 
lexcluziune", se are în vedere, implicit, un fanion de excluziune 
pasiv. 
i 

Se numește fanion de excluziune activ un fanion de 


excluziune a cărui tratare conduce la apelarea dispecerului. 


6.2.2.1. Excluderea mutuală prin fanioane 
de excluziune pasive 


Realizarca excluderii mutuale referitoare la o anumită 
resursă printr-un fanion de excluziune pasiv, se poate asigura 
prin instituirea şi respectarea următoarei convenții: 

1). fanionul de excluziune este asociat resursei în cauză şi 

numai ci 

2). valoarea "0" a fanionului arată că nici o secțiune critică 
referitoare la resursă nu este în derulare, iar valoarea "1" 
-contrariul; 

3). înainte de pătrunderea în secţiunea critică relativă la 
resursa în discuţie, orice task are obligația de a 
proceda la: 

A). efectuarea, în condiții de indivizibilitate, a operaţiei 

TAS asupra fanionului. 

B). a). repetarea obligaţiei în curs de definire, 
începând cu A), dacă operația TAS a găsit 
fanionul la "1" 

b). iniţierea secțiunii critice, dacă operaţia TAS 
a găsit fanionul Ía "0". 

4). la părăsirea secţiunii critice, orice task are obligaţia de 
a proceda la: 

A"). efectuarea operaţiei RES asupra fanionului. 


Într-adevăr, prin această convenție, dată fiind 
indivizibilitatea operaţiei TAS, se garantează imposibilitatea de 
a ajunge mai multe taskuri să găsească fanionul la "0" într-un 
același ciclu de evoluţie a valorii acestuia de la "1" la "0" şi 
înapoi la "1" şi, în consecinţă, se asigură realizarea excluderii 
mutuale. 
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Transpunerea în fapt a celor de mai sus se poate face, de 
exemplu, cu ajutorul a două macroinstrucții, corespunzătoare 
operaţiilor A) și B), respectiv A"), plasate la începutul, 
respectiv la sfârşitul  secțiunilor critice.  Denumim 
macroinstrucția corespunzătoare operaţiilor A) şi B) 
_a wait(), iar pe cca corespunzătoare operației A") _a_signalĝ. 
Aceste macroinstrucții pot fi definite astfel: 


define _a wait (flag) asm(flag db 0; mov al, 1; Ni 


loop xchg al, flag; oral, al; jnz loop;} 


define _a_signal (flag) asm(mov, flag, 0;) 


b). 


Notă: 
S-a presupus că numele variabilei care implementează 
fanionul de excluziune este flag. 


Fig. 6.2.2.1_1. Definirea macroinstrucțiilor _cz_mezit() şi _a signal). 


Pentru o mai bună lizibilitate a secvențelor de program care 
implementează macroinstrucţiile _a_wait() şi _a_signal(), 
redăm, în continuare, în figurile 6.2.2 2 și 6.2.2 3, o altă 
dispunere în pagină a textului lor -dispunerea uzuală din 
programarea în limbaje de asamblare-. 


1 flag db 0 

2 mov al,1 

3 loop: xchg al,fiag 

4 ; se forțează conținutul locației de 
5 ; memorie flag la "1", printr-o operație 
6 ; indivizibilă 

7 or al,al 

8 jnz loop 


; se ciclează în aşteptarea găsirii valorii 
; logice "0" în variabila flag la demararea ; 
; instrucției 3, valoarea ei în acest punct 
; Fiind oricum "1" 


Fig. 6.2.2.1_2. Secvența de instrucții în limbaj de ansamblare 
corespunzătoare macroinstrucției _a_wait(). 
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Fig, 6.2.2.1_3. Instucția în limbaj de ansamblare corespunzătoare 
macroinstrucției _a_signal(). 


Mecanismul de excludere mutuală prin fanioane de 
excluziune pasive prezintă marele neajuns că ocazioncază o 
irosire a timpului de lucru al procesorului, prin aceea că lasă 
taskurile ce găsesc un fanion la "1" să rămână în continuare 
vulabile și să intre normal în execuție fizică, de fiecare dată 
când le vine rândul prin politica de dispecerizare în vigoare, 
deși ele nu au posibilitatea de a avansa în misiunea lor, rulând 
doar bucla de așteptare activă reprezentată de instrucțiile din 
liniile 3, 7 şi 8 ale figurii 6.2.2_2, până la surprinderea trecerii 
la "0" a valorii fanionului. 


Un alt neajuns al mecanismului de excludere mutuală prin 
fanioane de excluziune pasive constă în faptul că permite 
apariția unor interblocaje. De exemplu, dacă într-un sistem cu 
dispecerizare prin prioritizare, un task A, de o anumită 
prioritate, intră într-o secţiune critică legată de un fanion eps, 
pe care îl poziţionează, cu această ocazie, la "1", şi ajunge să 
iasă din rulare, ca urmare a sosirii momentului unei comutări, 
fără a-şi încheia secţiunea critică, iar în locul lui, devenind 
rulabil (în intervalul de timp scurs de la precedenta 
dispecerizare), ajunge la procesor un alt task, B, mai prioritar 
decât A, şi execută macroinstrucția _a_wai(eps), atunci acest 
task B va intra în bucla de aşteptare din cadrul macroinstrucţiei 
_a_wait(eps) şi va cicla pe ea la nesfârşit. Evident, ciclarea nu 
va avea loc continuu, ci în reprize impuse de activarea 
periodică şi/sau neperiodică a procesului de dispecerizare. Se 
poate subînțelege că se ajunge la "împotmolirea” taskului B în 
bucla respectivă, datorită faptului că, în competiția pentru 
obţinerea procesorului, taskul A, singurul care ar putea aduce 
fanionul eps la valoarea "0", creind, astfel, condiţii pentru 
avansarea taskului B, va fi întotdeauna fără şansă în fața 
taskului B, mai prioritar decât el. Aşadar, taskul A va aştepta 
ca taskul B să-i permită accesul la procesor, iar taskul B va 
aştepta ca taskul A să-i permită să-şi ruleze secțiunea critică. 
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eee 


Merită menţionat că, într-un sistem cu dispecerizare prin 
rotaţie, interblocaje de tipul celui relevat nu pot apărea. 


De asemenea, mecanismul de excludere mutuală prin 
fanioane de excluziune pasive nu garantează că un task 
oarecare nu va fi mereu devansat de altele în găsirea unui 
fanion la zero, ajungând, astfel, în imposibilitatea de a accede 
la resursa critică asociată respectivului fanion. 


Pe de altă parte, acest mecanism prezintă avantajul că este 
uşor de implementat. Cu atenţia de rigoare, el poate fi -şi este, 
de altfel- folosit cu succes. 


—6.22:2-Excluderea mutuală prin fanione de 
excluziune active 


Un fanion de excluziune activ este un ansamblu format 
dintr-un fanion de excluziune pasiv, F, şi o coadă de 
așteptare, C. 


Fanionul de excluziune pasiv are rolul de a indica, printr-o 
operaţie TAS, posibilitatea sau imposibilitatea iniţierii de către 
un task, la un moment, a secțiunii sale critice referitoare la o 
resursă pusă în corespondență cu fanionul. 


Coada de aşteptare serveşte înregistrării taskurilor 
nesatistăcute în tentativa lor de a-și demara secțiunea critică 
referitoare la resursa corespunzătoare fanionului. 


Mecanismul de excludere mutuală prin fanioane de 
excluziune active este dezvoltat în jurul următoarei convenții: 


1). fanionul de excluziune este asociat resursei în cauză şi 
numai ei 

2). valoarea "0" a componentei F a fanionului arată că nici 
o secțiune critică referitoare la resursă nu este în 
derulare, iar valoarea "1" -contrariul 

3). înainte de pătrunderea în secțiunea critică relativă la 
resursa în discuție, orice task are obligația de a 
proceda la: 
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A). efectuarea, în condiții de indivizibilitate, a 

operaţiei TAS asupra fanionului. 

B). a).autoînscrierea în coada C a  fanionului, 
autoeliminarea din lista taskurilor rulabile, 
autoblocarea şi  autoinscrierea în lista 
taskurilor blocate, apelarea  dispecerului şi 
repetarea, după deblocare, a obligaţiei în curs de 
definire, începând cu A) -toate acestea dacă 
operaţia TAS a găsit componenta F la "1". 

b). inițierea secțiunii critice, dacă operaţia TAS a 
găsit componenta F la "0". 
4). la părăsirea secţiunii critice, orice task are obligaţia de a 
proceda, printr-o secvență indivizibilă, la: 

A"). efectuarea operației RES asupra componentei F a 

fanionului 

B'). deblocarea tuturor taskurilor înscrise în coada C a 

fanionului şi, implicit, vidarea acesteia, şi 
reînscrierea lor în lista taskurlor rulabile. 


Se remarcă faptul că acest mecanism elimină aşteptarea 
activă, dar, cu preţul creşterii considerabile a complexităţii sale 
în raport cu cea a mecanismului bazat pe fanioane pasive. 


Utilizarea facilă a mecanismului de excludere mutuală prin 
fanioane de excluziune active presupune definirea a două 
funcţii, corespunzătoare, una dintre ele, operațiilor A) şi B), iar 
cealaltă, operaţiilor A') şi B'), funcţii care să fie plasate 
înaintea, respectiv la sfârșitul secțiunilor critice. 


Denumim aceste funcţii _/ wait), respectiv _f signal(). 
Vom considera că, pentru efectuarea acțiunilor scrise cu 
caractere italice în textele corespunzătoare operaţiilor B), 
respectiv B'), funcţia _£_ waiz() face apel la o funcție pe care o 
denumim _sleep(), iar funcția _f_signal() -la o funcţie pe care o 
enumim  _wakeup(. Intrucât experiența în domeniul 
sistemelor multitasking în timp real a relevat utilitatea limitării 
duratelor intervalelor de timp în care taskurile sunt ținute 
blocate, funcția _sleep() se prevede cu un argument, căruia îi 
dăm numele timeout, prin care se poate specifica, în perioade 
ale ceasului de timp real, timpul după care taskul blocat va fi 
automat deblocat. Această funcţie va fi astfel concepută încât, 
dacă la apel va găsi argumentul cu valoarea zero, atunci va 
bloca taskul în cauză pe termen nedefinit. 
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Indiferent dacă valoarea argumentului fimeout este zero sau 
diferită de zero, în cadrul funcţiei _sleep() ea se atribuie 
câmpului slime al structurii CONTLOG a taskului în care 
funcția se execută, urmând a fi folosită de către dispecer 
(scheduler()) aşa cum s-a arătat în capitolul 3 (vezi figura 3_8). 


Taskurile blocate cu ajutorul funcţiei _sfeep() vor fi înscrise 
într-o listă dedicată, lista taskurilor blocate, pe care o vom 
referi prin abrevierea //b. Asupra acestei liste, se va opera 
cu ajutorul unor funcţii clasice, cărora le dăm numele: 
ins_ltb(), elim_ItbQ, next_Ib(Q şi init_Ub(Q. Ele fac obiectul 
figurii 6.2.2.2_1. 


void ins_ltb(uschar tskid) 
/* inserează în lb taskul cu indexul rshid */ 


void elim_lb(uschar ind _ltb) 
/* elimină din lb taskul cu indicele /skid */ 


uschar next _ltb(void) 
/* determină indexul taskului aflat în capul /4b */ 


void init_ltb(void) 
/* iniţializează lista taskurilor blocate */ 


Fig. 6.2.2.2_1. Funcţiile de gestionare a listei taskurilor blocate. 


Se menționează că apelantul funcției _sleep() va putea afla, 
la revenirea din aceasta, dacă deblocarea s-a făcut normal, în 
limita de timp fixată prin argumentul zimeout sau forțat, la 
expirarea timpului, cu ajutorul unei funcţii speciale, _rochk(). 
Funcţia _fochk() arc rolul de a furniza valoarea câmpului fo din 
structura CONTLOG a taskului curent, prin intermediul unei 
variabile fanion, al cărui pointer trebuie să apară pe post de 
argument al funcției. 


Ținând seamă de cele de mai sus, funcţiile _s/eepţ), 
_wakeup() şi _tochk( pot fi implementate în C aşa cum se 
propune în figurile 6.2.2.2_2, 6.2.2.2_3, respectiv 6.2.2.2 4. 
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void _sleep (usint timeout) { 
CONTLOG *p; 
lock () ; 
p=6_contlog|_tsk_crt] ; 
p->status=BLOCAT ; 


p->sltime=timeout ; i 

p->to=0; i 

elim lap (_tsk_ert) F i 

ins_Ltb(_tsk_crt); i 

sched () ; i 

_unlock () ; 
} 


Fig. 6.2.2.2_2. Textul funcției sleep(). 


void _wakeup (uschar tskid){ 

CONTLOG *p; 

_lock(); 

p=&_contlog[tskid] ; i 

if (p->status==BLOCAT) { pi 
p->status=EXECUTIE; i 
p->sltime=0; i 
elim_Ltb (tskid); i 
ins_lap (tskid) ; | 


PWOANUBWNPDI- 


} 
11 _unlock(); 
12 ) 


Fig. 6.2.2.2_3. Textul funcției _wakeup(). 
void _tochk (uschar *flgadr) | 


_lock () ; 
*£lgadr=_contlog [_tsk_ert].to; 


_contlog [_tsk_crtl „to=0; 
_unlock () 3 


) 


Fig. 6.2.2.2_4. Textul funcţiei _fochk(). 
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Pentru implementarea mecanismului de excludere mutuală 
prin fanioane active, este utilă definirea unui tip de dată, pentru 
care adoptăm numele FLAG, ca o structură cuprinzând: 

- o variabilă de tipul uschar, reprezentând fanionul de 
excluziune pasiv; fie fan numele acestei variabile; 

- un tablou de tipul uschar, cu MAX _1SK elemente, 
dedicat a servi drept coadă a fanionului de excluziune 
activ; fie coada[] numele acestui tablou. 

- o variabilă de tipul pointer către un caracter fără semn, 
având rolul de a asista intrarea în şi ieşirea din coada 
fanionului; fie pie numele acestei variabile. 


Tipul de dată FLAG se va introduce, deci, printr-o declarație 
de forma: 


typedef structi 
uschar fan; 
uschar coada [MAX_TSK] ; 
uschar *pie; 

}FLAG; 


Fig. 6.2.2.2_5. Tipul de dată FLAG. 


Este firesc ca toate fanioanele de excluziune active de care 
se dispune în sistem să fie grupate sub forma unui tablou. Dacă 
admitem că numărul maxim de asemenea fanioane este 
MAX _FLG, atunci acest tablou -fie _/lg// numele lui- va fi 


FLAG _flg[MAX_FLCG]; 


Fig, 6.2.2.2_6. Declararea tabloului de fanioane _/lg/]. 


Este de subînțeles că declaraţia de mai sus trebuie să apară în 
afara oricăror acolade, fiind necesar ca tabloul _flg// să aibă 
statut de variabilă globală, deci: să fie cu locare statică în 
memorie. 


În această situaţie, un fanion de excluziune activ va fi 
exploatat cu ajutorul indicelui său în cadrul tabloului de 
fanioane, introducând câte un indentificator pentru fiecare 
indice. Este practic ca valoarea unui asemenea identificator să 
fie stabilită printr-o funcţie care asigură alocarea elementelor 
tabloului de fanioane; o asemenea funcție este calificată ca 
fiind de creare a unui fanion. O vom denumi _f create). 
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Existenţa unei funcţii de alocare a elementelor tabloului de 
fanioane atrage după sine necesitatea existenței şi a unei funcții 
de dezalocare. Întrucât este obişnuit ca, în anumite contexte, 
acţiunea de dezalocare să fie considerată ca o distrugere a 
ceva, funcţia de dezalocare a elementelor tabloului de fanioane 
va fi denumită _f destroy(). 


În fine, mecanismul de excludere mutuală prin fanioane de 
excluziune active va mai dispune de o funcţie de inițializare a 
tabloului de fanioane, funcție denumită _f_îni/(). 


În figura 6.2.2.2_7, este redat, sintetic, ansamblul celor cinci 
funcții prin care utilizatorul poate face referiri la fanioanele de 
excluziune active. 


void _f init(void) 
7" inițializează tabloul de fanioane 


void _f_create(uschar *flgidadr) 
/* creează un fanion, furnizând indicele elementului */ 
/* tabloului _/lg/] pe care îl alocă */ 
/* în variabila pointată de Jlgidadr */ 


void _f destroy(uschar flgid) 
/* distruge un fanion, dezalocând elementul aferent */ 
/* din tabloul _Alg/]; argumentul /igid reprezintă */ 
pt indicele respectivului element */ 


void _f wait(uschar flgid, usint timeout) 

/* asigură, dacă este cazul printr-o aşteptare */ 
/* limitată superior de argumentul fizmeout, ca taskul */ 
/* curent să-şi poată iniția secțiunea critică */ 
/* referitoare la resursa asociată fanionului */ 

/* cu indicele figid */ 


void_f signal(uschar flgid) 
/* semnalează. încheierea unei secțiuni critice */ 
/* referitoare la resursa asociată fanionului cu */ 
/* indicele /lgid -deblocând toate taskurile aflate */ 
/* în coada acestuia */ 


Fig. 6.2.2.2_7. Funcţiile aferente mecanismului de excludere mutuală 
prin fanioane de excluziune active. 
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Funcţia _f_iniz Q 


Această funcţie arc rolul de a inițializa tabloul de fanioane 
_flg[], prin stabilirea valorii NULL pentru componentele pie 
ale tuturor elementelor sale. 


Textul C al funcţiei _/ inir() este următorul: 


void _f_init(void) 4 

FLAG *£; 

uschar j; 

_lock () ; 

f=&_flg[0]; 

For (j=0;j<MAX_FLG; j++) | 
f->pie=NULL; 
EPER 

) 


_unlock () ; 


i 


îROWVONNUBUNI 


li 


Fig, 6.2.2.2_8. Textul funcţiei finit). 


Funcţia _f create() 


Funcţia _/ create() are rolul de a identifica un element liber 
al tabloului de fanioane _/g// şi de a-l aloca, furnizând 
indicele-i în variabila pointată de argumentul său. 


De asemenea, funcţiei _f create() îi revine sarcina de a 
poziţiona pointerul pie al fanionului pe care îl alocă pe primul 
element al cozii şi de a iniţializa la valoarea "0" componenta 
fan a acestui fanion. 


Textul C al funcţiei _/ create() este redat în figura 6.2.2.2_9. 


void _ f create(uschar *flgidadr) | 
FLAG *£; 
uschar j; 
_lock () ; 
f=s_flg [0]; 


AUBWNWHR 


Fig. 6.2.2.2_9. Textul funcţiei _/ create) -partea întâi. 
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while ( (£->pie) 66 (3<MAX_FLG) ) | 


8 £++; 
9 Jtt; 
10 } 
11 if (j<MAX_FLG) { 
12 £->pie=s (£f->coada [0]) ; 
13 £->fan=0; 
14 } 
15 else{ 
16 abort ("Eroare in taskul %2d: Tentativa 
17 de a crea mai mult de MAX FIG (%2d) 
18 fanioane!", _tsk crt, MAX FLG); 
19 ) 


20 *Elgidadr=j ; 
| 21  _unlock(); 
| 22) 


Fig. 6.2.2.2_10. Textul funcției _/ create) - partea a doua. 


Funcţia _f destroy) 


Funcţia _/ destroy() are rolul de a dezaloca elementul 
tabloului de fanioane _/lg// cu indicele specificat prin 
argumentul ei, atribuind valoarea NULL componentei pie a 
acestui element, În acest fel, elementul în cauză este lăsat la 
dispoziţia funcţiei _/ create(), în vederea unei noi alocări. 


Se precizează că este interzisă distrugerea unui fanion a 
cărui coadă este nevidă. De aceea, funcția _/ destroy) va 
efectua o verificare a cozii fanionului vizat a fi distrus şi va 
proceda la distrugere doar dacă coada este vidă. Altfel, 
acțiunea funcției se va rezuma doar la generarea unui mesaj de 
eroare. 


Textul C al funcției _f destroy) este redat în figura 
6.2.2.2_11. 
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1 void _£ destroy(uschar flgid){ 

2 FLAG *f; 

3 _lock(); 

4 E=e flglflgid]; 

5 i£ (£->pie!=& (£->coada [0])) i 
6 abort ("Eroare in taskul $2d: Tentativa 
7 de a distruge un fanion (%2d) cu 

8 coada nevida!", _tsk crt, £lgid); 

9 } 

10 else{ 

11 f->pie=NULL; 
12 } 


13 _unlock () ; 


Fig. 6.2.2.2_11. Textul funcţiei _/ destroyQ). 


Funcţia _f_wait() 


Funcţia _f wait) are rolul de a efectua operaţia TAS asupra 
componentei fan a fanionului cu indicele flgid și de a permite 
taskului care o execută inițierea secțiunii sale critice, dacă 
această operație găseşte componenta fan la valoarea "0", 
respectiv de a bloca acest task şi de a-l înscrie în coada 
fanionului, în caz contrar. 


Operația de blocare a taskului în cauză se execută prin apelul 
funcţiei _sleep(). Întrucât este util ca prin funcția _/ wait() să 
se fixeze şi un timp limită în care taskul curent poate rămâne 
blocat, această funcţie este prevăzută cu argumentul timeout, 
menit să fie pasat neprelucrat de către ca funcției _s/eep(). 
Dacă la expirarea timpului precizat prin acest argument, taskul 
în cauză este încă blocat, se va produce deblocarea lui 
automată. O asemenea deblocare denotă o anomalie, care 
trebuie tratată în mod corespunzător de către utilizator. 
Evident: tratarea anomaliei presupune mai întâi detectarea ei, 
detectare realizabilă cu ajutorul funcției _/ochk(). 


Textul C al funcției _/_wairQ este următorul: 
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void £ wait(uschar flgid, usint timeout) ( 
FLAG *£; 

3 _lock () ; 

4 f=& flg[flgid] ; 

5 while ((£->£1g) && (!_contlogi_tsk_ert] .to)) | 

6 *£->pie=_tsk_crt; 

7 (£->pie)++; 

8 _sleep (timeout) ; 

9 ) 

0 if(!_contlog[_tsk_crt] .to){ 


11 £->fan=1; 

12 ) 

13 _unlock () ; 
) 


Fig, 6.2.2.2_12. Textul funcţiei _/ wait (). 


Funcţia _f signal) 


Funcţia _f signal) are rolul de a efectua operația RES 
asupra componentei fan a fanionului cu indicele figid şi de a 
debloca toate taskurile aflate în coada acestui fanion. 


Deblocarea taskurilor se asigură prin apelul funcției 


_wakeup(). 


Dacă nici un task nu este găsit în coadă, funcția _/ signal) 


rămâne fără nici un rezultat. 


Textul C al funcției _/ signal este redat în figura 
6.2.2.2_ 13. 
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1 void _f signal (uschar flgid){ 
2 FLAG *£; 
3 uschar k; 
4 _lock () ; 
5  f=& flgifigia]; 
6 while ( (£->pie) !=& (£->coada [0])) 
7 (£->pie) --; 
8 k=* (£->pie) ; 
9 * (£->pie) =MAX_7SK; 
10 _wakeup (k) ; 
11 ) 
12 _unlock () ; 
13) 


Fig, 6.2.2.2_13. Textul funcției _/ signal). 


ÎNTREBĂRI: . 


1): Definiţi noțiunea de fan on de:ex 
2). În ce consistă mecanismul fanioanelor pa 
3). Precizaţi rolul'macroinstrucției.a.. wait.. 
4). Descrieți acțiunile macroinstructiei u. wait); 
5). Daji o implementare pentru macroinstructia ü: wait). 
6). Precizaţi rolul macroinstrucției a.sienalQ. 
7). Descrieţi acțiunile macroinstrucției a. signal(): 
8). Daţi o implementare pentru macroinstrueția a signal). 
9). Cum se asigură excluderea mutuală prin mecanismul | 
fanioanelor pasive? 
10). Ce avantaje prezintă mecanismul Janioanelor pasive? 


pasive? : 
12). -Definiţi noțiunea. de fanion activ. 
13). Ce este, în plan practic; un Janion acliv? 
14). În ce consistă mecanismul fanioanelor active? 
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15). Pr acean rolul functiei Je init. 
16). Descriefi acțiunile functiei _f. inito. ; 
I7). Dati o implementare C pentru, funcția finit). 
18). Precizaţi rolul fiineţiei_f.createQ. 
19). Descrieţi acțiunile funcției f creat Q... 
20). Dați o implementare C pentru funcția A create. 
21). Precizaţi rolul funcției f. destroy. 
22). Descrieti actiunile functiei f. destroyo. 
23): Dați o implementare C pentru funcția f. destrayo; 
24). Precizaţi rolul funcției _f. waitQ. 
25). Descrieți actiunile funcției. f waitQ. 
26). Daţi o implementare C pentru funcția _f.waitQ. 
27). Precizăţi rolul funcţiei ..f. sisnalO. 
28). Descrieţi acțiunile funcției f. signal. 
Daţi o implementare C pentru functia _f_signalQ. 
). Cum se. asigură excluderea. ` mutuală prin 
mecanismul o : 
fanioanelor active? o 
avantaje... prezintă mecanismul . fanioanelor! 


taje prezintă mecanismul fanioanelor: 


6.2.3. Excluderea mutuală prin 
semafoare 


Dezavantajele mecanismelor de realizare a excluderii 
mutuale anterior discutate nu sunt, deloc, de neglijat. 


Excluderea mutuală prin fanioane active nu poate fi 
apreciată nici ea în termeni prea elogioși. Soluția adoptată în 
cazul ei pentru evitarea așteptării active are dezavantajul că, 
deşi se ştie că de fiecare dată când un fanion ajunge la valoarea 
"0", doar un task îşi poate efectua secțiunea critică în legătură 
cu respectivul fanion, atingerea acestei valori determină, în 
toate ocaziile, introducerea tuturor taskurilor care o aşteaptă în 
"lupta" pentru a profita de ea. Ori, dacă durata secțiunii critice 
este mai mare decât perioada procesului de comutare, la prima 
activare a acestui proces, doar unul dintre taskurile concurente 


=) 


va rămâne rulabil, celelalte reblocându-se şi reânscriindu-se 
rând pe rând în lista din care abia au fost şterse. Şi este de 
subînțeles că, până să revină de unde au plecat, aceste taskuri 
consumă o anumită cantitate de timp procesor. 


Să abordăm, acum, mecanismul de realizare a excluderii 
mutuale prin semafoare. 


Semafoarele au fost introduse în 1965, de către olandezul 
E.W.Dijkstra [7]. 


Un semafor S este un ansamblu format dintr-o variabilă 
întreagă T şi o coadă de aşteptare | C. În momentul creerii 
semaforului, variabilei i se atribuie o valoare inițială 1, 
nenegativă, iar coada este vidă. si 


Asupra semafoarelor sunt definite două funcţii, denumite P 
(de la cuvântul olandez Passeren = a trece), respectiv V (de la 
cuvântul olandez Vrygeven = a elibera). Doar prin intermediul 
acestora se poate acționa asupra variabilei I şi asupra cozii C. 
Funcţiile P şi V se execută în condiţii de indivizibilitate şi se 
numesc primitive. 


Primitiva P(S) constă în următoarele operații: 

I.I. 

2). Dacă I>=0, funcţia se încheie și taskul în care ea se 
execută îşi continuă rularea. 

3). Dacă 1<0, taskul în care funcţia se execută iese din 
rândul taskurilor rulabile, se blochează şi este înscris 
în coada de așteptare C, provocându-se un proces de 
comutare pentru introducerea în rulare a unui alt task. 


Primitiva V(S) constă în următoarele operaţii: 
DIS. 
2). Dacă I>0, funcţia se încheie și taskul în care ca se 
execută îşi continuă rularea. 
3). Dacă I<=0, se deblochează taskul aflat în capul cozii 
C, extrăgându-se din ea şi se introduce în rândul 
taskurilor rulabile. ` 
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În figurile 6.2.3_1 şi 6.2.3 2 se prezintă sugestiv operaţiile 
celor două funcții. 


I=1-1 


NU 


| 


se scoate taskul curent dintre taskurile 
rulabile, se blochează și are loc 
înscrierea lui în coada C 


l 


se face apel la dispecer 


DA 


Fig. 6.2.3_1. Primitiva P(S). 


NU 
— DA 
se deblochează taskul aflat în capul 
cozii C şi se elimină din ea, având loc 
înscrierea lui între taskurile rulabile 
> 
Fig. 6.2.3_2. Primitiva V(S). 5 


128 


În timpul funcției P(S), în situația în care, în urma 
decrementării, 1<0, se dă controlul dispecerului, pentru a scoate 
din rulare taskul curent, întrucât el nu-şi poate iniția secţiunea 
critică, și a introduce în rulare un alt task. Abia mai târziu, când 
secțiunea critică poate fi executată, taskul blocat prin funcția 
P(S) va fi reintrodus în rulare. 


Din definirea primitivelor P(S) şi V(S), rezultă următoarele 
semnificaţii ale valorilor variabilei I: 
- dacă 1>0, atunci I reprezintă numărul de taskuri care 
pot executa funcția P(S) fără a se bloca, presupunând 
că, între timp, nu se execută nici o dată funcţia V(S). 
- dacă 1<=0, atunci | reprezintă numărul de taskuri 
aflate în coada C, blocate la semaforul S. 


Devine evident, acum, că un semafor utilizat în realizarea 
excluderii mutuale a secţiunilor critice trebuie să aibă valoarea 
I=! şi că exploatarea resurselor partajabile cu "n" puncte de 
acces se poate face sub controlul unui semafor cu valoarea 
iniţială Lo=n. 


Semafoarele cu valoarea iniţială egală cu 1 se numesc 
semafoare binare sau semafoare cle excluziune, iar semafoarele 
cu valoarea inițială diferită de 1 -semafoare generalizate. 


Bazat pe faptul că valoarea variabilei unui semator 
evoluează doar prin incrementare și decrementare, ea este 
denumită contorul semaforului. 


În ceea ce priveşte coada semafoarelor, se face menţiunea că 
ca este gestionată, de obicei, fie după principiul FIFO (First 
In, First Out), fie pe bază de priorități -univoce sau ncunivoce-. 
Noi vom considera, în cele ce urmează, gestiunea FIFO. 


Pentru implementarea mecanismului de excludere mutuală 
prin semafoare, se defineşte tipul de dată SEMAPHORE, ca o 
structură cuprinzând: 

- o variabilă de tipul short, reprezentând contorul 
semaforului; fie contor numele acestei variabile 
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- un tablou de tipul uschar, cu MAX_TSK elemente, 
dedicat a servi drept coadă a semaforului; fie coada// 
numele acestui tablou 

- o variabilă de tipul pointer către un caracter fără semn, 
având rolul de a asista intrarea în coada semaforului; 
fie pi numele acestei variabile, ca abreviere de la 
pointer de intrare 

- o variabilă de tipul pointer către un caracter fără semn, 
având rolul de a asista ieşirea din coada semaforului; 
fie pe numele acestei variabile, ca abreviere de la 
pointer de ieşire 

- o variabilă de tipul aschar, destinată memorării valorii 
iniţiale a variabilei contor; fie va/ini numele acestei 
variabile. 


Tipul de dată SEMAPHORE se va introduce, deci, printr-o 
declarație de forma: 


typedef struct 
short contor; 
uschar coada [MAX_TSK] ; 
uschar *pi; 
uschar *pe; 
uschar valinit; 
} SEMAPHORE ; 


Fig. 6.2.3_3. Declararea tipului de dată SEMAPHORE. 


Este firesc ca toate semafoarele de care se dispune în sistem 
să fie grupate sub forma unui tablou. Dacă admitem că 
numărul maxim de semafoare este MAX_SEM, atunci acest 
tablou -fie _ser// numele lui- va fi declarat astfel: 


SEMAPHORE _sem[MAX_SEM] ; 


ig. 6.2.3_4. Declararea tabloului de semafoare _sem{]. 


Este de subînțeles că declaraţia de mai sus trebuie să apară în 
afara oricăror acolade, fiind necesar ca tabloul _sem/] să aibă 
statut de variabilă globală, deci: să fie cu locare statică în 
memorie, 
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În această situaţie, un semafor concret va fi exploatat cu 
ajutorul indicelui său în cadrul tabloului de semafoare, 
introducând un identificator pentru fiecare indice. 


Dată fiind importanța şi delicatețea semafoarelor într-un 
sistem multitasking, se impune ca utilizatorul să poată face 
referiri la ele doar prin intermediul unor funcţii ale 
executivului. Clasic, acestea sunt cele prezentate, sintetic, în 
figura 6.2.3_5. 


void _5_init(void) 
/* iniţializează tabloul de semafoare prin */ 
/* atribuirea valorii NULL componentelor */ 
pe pi ale elementelor sale nj 


| 
void _s_create(uschar *semidadr, uschar initval) | 
/* alocă un element al tabloului _sem{}, */ i 
atribuie componentelor contor şi valinit ale elementului */ | 
* alocat valoarea initval şi furnizează indicele */ l 
/* acestui element în variabila pointată de semidadr */ i 
i 

| 

f 

i 

i| 

H 

| 


void _s_destroy(uschar semid) 

t dezalocă elementul tabloului _sem/] cu */ 
* indicele semid, punându-l la dispoziţia */ 
pe funcţiei s_create() */ 

m | 
Void _S_ wait(uschar semid, usint timeout) 
Y*_efectucāzā funcția P asupra semaforului 
/* cu indicele semid şi înregistrează */ 
/* valoarea argumentului fimeout ca timp */ 
/* limită în care taskul curent trebuie */ 
/* să treacă de semafor */ 


$ 
j 


void _s$_signal (uschar semid) 
/* efectuează” functia V asupra semaforului */ 
pe cu indicele semid +/ 


Fig. 6.2.3_5. Funcțiile relative la semafoare. 


131 


CAP. 6. CONFLICTE... SOLUȚII... EXCLUDEREA MUTUALĂ 


CAP. 6. CONFLICTE... SOLUȚIE... EXCLUDEREA MUTUALĂ 


Funcția _s_init() 


Această funcţie are rolul de a inițializa tabloul de semafoare, 
prin stabilirea valorii NULL pentru componetele pi ale tuturor 
elementelor sale. 


Textul C al funcţiei _s_init() este următorul: 


1 void _s_init(void) { 
2 SEMAPHORE *s; 
3 uschar j; 
4 uschar i; 
5 _lock(); 
6 s=&_sem[0]; 
7 for (j=0;j<MAX_SEM; j++) { 
8 s->pi=NULL; 
9 for (i=0;i<MAX_TSK; i++) ( 
10 s->coada [i]=MAX_7SK; 
11 ) 
12 S++; 
13 } ! 
14  _unlock(); po 


g. 6.2.3 _6. Textul funcției _s_init (). 


Funcţia _s_create() 


Din punct de vedere al utilizatorului, funcția _s_create() are i 
rolul de a identifica un clement liber al tabloului de semafoare | 
_sem{] şi de a-l aloca, atribuind componentelor sale contor şi | 
valinit valoarea precizată prin argumentul initval; indicele į 
elementului este făcut cunoscut apelantului prin intermediul i 
variabilei pointate de argumentul semicdadr. În plus, acestei i 
funcţii îi revine şi sarcina de a pregăti semaforul alocat pentru | 
acțiunile pe care funcțiile _s wait) şi _s_ sienalQ le vor i 
intreprinde asupra sa. Achitarea acestei sarcini comportă i 
poziționarea pointerilor pi şi pe din componența sa, către i 
primul element al cozii. i 


Rezultă pentru funcţia _s creafe() textul C din figura 
6.2.3_7. 


1 void _s_create(uschar *semidadr, 
2 uschar initval){ 
3 
4 


SEMAPHORE *s; 
uschar j; 


5 _lock () ; 

6 s=&_sem[0]; 

7 j=0; 

8  while((s->pi)&6 (j<MAX SEM)) ( 

9 S++; 
10 j++; 
11 } | 
12 i£(3<MAX SEM) ( | 
13 s->contor=initval; i 
14 s->pi=& (s->coada[0]) ; | 
15 s->pe=& (s->coada[0]) ; | 
16 s->valinit=initval; 

17 ) 

18 elsej 

19 abort ("Eroare in taskul %2d: Tentativa 
20 de a crea mai mult de MAX SEM (%2d) 

21 semafoare, _tsk_ crt, MAX_SEM") ; 

22 ) 


23 *semidadr=j ; 
24 _unlock() ; 


ig. 6.2.3_7. Textul funcţiei _s_create(). 


Funcţia _s_destroy() 


Din punct de vedere al utilizatorului, funcția _s_desroy() 
are rolul de a dezaloca elementul tabloului de semafoare 
_sem[] cu indicele specificat prin valoarea argumentului ei. 
Dezalocarea se realizează prin readucerea componentei pi a 
acestui element la valoarea inițială NULL. În urma acțiunii 
funcţiei  _s destroy, elementul în cauză este lăsat la 
dispoziţia funcției _s_create(), în vederea unei noi alocări. 
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Se precizează că regulile care guvernează lucrul cu 
semafoare interzie distrugerea unui semafor asupra căruia s-au 
efectuat de numere de ori inegale primitivele P şi V. 


Fidelă fiind acestor reguli, funcția _s_destroy() va efectua o 
confruntare între valorile câmpurilor contor şi valinit ale 
semaforului asupra căruia planează perspectiva distrugerii și îl 
va distruge doar dacă cele două valori sunt egale. Altfel, 
acţiunea funcției se va rezuma la generarea unui mesaj de 
eroare. 


Textul C al funcţiei _s_destroy() este următorul: 


1 void _s_destroy(uschar semid) ( i 
2 SEMAPHORE *s; | 
3 _lock(); H 
4 s=&_sem[semid] ; | 
5 i£ (s->contor!=s->valinit) | | 
6 abort("Eroare in taskul $2d: Tentativa | 
7 de a distruge un semafor (%24) i 
8 incarcat!", _tsk_crt, semid) ; i 
93 3} | 
10 else{ | 
11 s->pi=NULL; 

12 ) 


13 _unlock () ; 


Fig. 6.2.3_8. Textul funcţiei _s_destroy(). 


Funcţia _s_wait() 


Funcţia _s_waif () are rolul de a materializa operațiile care 
definesc primitiva P, cu referire la semaforul precizat prin 
primul său argument. O parte dintre aceste operaţii, şi 
anume: cele de scoatere a taskului curent dintre taskurile 
rulabile şi de blocare a acestui task, sunt asigurate prin apelul 
funcției s/eep(). 
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Cel de-al doilea argument al funcției _s_wair() este destinat 
transmiterii lui la funcţia _sleep(), în vederea limitării timpului 
cât taskul care o execută poate rămâne blocat la semafor. 
Ajungerea în situaţia deblocării automate a unui task pus în 
aşteptare la un semafor reprezintă o anomalie care trebuie 
tratată în mod corespunzător de către utilizator. Evident: 
tratarea anomaliei presupune mai întâi detectarea ei, detectare 
realizabilă cu ajutorul funcţiei _/ochk(). 


Legat de operaţia de înscriere a taskului curent în coada de 
aşteptare la semafor, se precizează că ea trebuie să se efectueze 
circular, prin repoziţionarea pointerului pi pe primul element al 
tabloului care implementează coada, după ce el a servit 
înscrierii unui task în ultimul element al acestui tablou. 


Conform celor de mai sus, funcţia _s_wai/() se poate 
implementa prin textul C redat în figura 6.2.3_9. 


void _s_wait (uschar semid, usint timeout)([_| 
SEMAPHORE *s; 
_lock () ; 
s=&_sem[semid] ; 
i£ (C-s->contor<0)() - 
*s->pi=_tsk crt; 
if (s->pi==& (s->coada [MAX_TSK-1]) ) 4 
s->pi=& (s->coada [0]) ; 
) 
else! 
(s->pi)++; 


1 
2 
3 
4 
5 
6 
7 
8 


H 
_Sleep (timeout) ; 


) 


_unlock 0: 


Fig. 6.2.3_9. Textul funcției _s_wait (). 


Este lesne de înțeles că, dacă în urma decrementării 
contorului semaforului valoarea acestuia cste negativă, 
funcția _s_wai() se va derula în două reprize. Prima repriză 
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va cuprinde liniile [1...14], iar a doua repriză -liniile [14...17). 
Asta înseamnă că o parte a funcției _sleep() - -linia 14- se va rula 
în repriza întâi, iar cealaltă parte -în repriza a doua. Între cele 
două reprize, va avea loc rularea altor taskuri, printre care, în 
mod normal, trebuie să fie şi cele care au executat înaintea 
taskului curent funcția _s_w air) cu referire la acelaşi semafor. 


Funcţia _s_signal() 


Funcţia _s_signal() are rolul de a materializa operaţiile care 
definesc primitiva V, cu referire la semaforul precizat prin 
argumentul său. O parte dintre aceste operații, și anume: cele 
de deblocare a taskului aflat în capul cozii semaforului şi de 
înscriere a acestui task în rândul taskurilor rulabile, sunt 
asigurate prin apelul funcției _wakeup(). 


Legat de operația de determinare a taskului aflat în capul 
cozii semaforului şi de eliminare a lui din această coadă, se 
precizează că ea trebuie să se efectueze circular, prin 
poziționarea pointerului pe către primul element al tabloului 
care implementează coada, după ce el a servit extragerii unui 
task înscris în ultimul element al acestui tablou. 


Rezultă următorul text C pentru funcția _s_signal(): 


void _S_signal (uschar semid) { 
SEMAPHORE *s; 
uschar k; 
_lock () ; 
s=&_sem[senid] ; 
i£ (++s->contor<=0) 4 
k=* (s->pe) ; 
* (s->pe) =MAX_TSK; 
if (s->pe==& (s->coada [MAX _TSK-1]) ) | 


DONDUOBRIWNI-— 


s->pe=& (s->coada [0]) ; 
} 
elsef{ 

(s->pe) ++; 


} 
_wakeup (k) ; 
} 
17 _unlock () ; 
18 } 


Fig. 6.2.3_10. Textul funcției _s_signal Q. 
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ÎNTREBĂRI: 


1). Definiţi notiunea: de semafor. 
2). Ce este, în plan practic, un semafor? 
3). ce consistă mecanismul semafoarelor? 

4). Precizaţi rolul funcției - S-init). 

5). Descrieţi actiunile fiuinctiei --s:-iînitQ. 

6). Daţi o implementare C pentru funcţia. <s initQ). 

7). Precizati rolul functiei: s create). 

$). Descrieti acțiunile fiincției. s-creat.0. 

9); Daţi o implementare C pentru functia ::s-:create(). 
10). Precizaţi rolul funcției Ss: destroy). 
11). Descrieţi actiunile functiei 5. destroy; 
12). Daţi o implementare C pentru funcţia. s dest 00). 
13). Precizaţi rolul funcției -s ait). : 
14). Descrieţi acțiunile funcției. S.. wait. 
15). Daţi o implementare C pentru. funcţia 
16).:Precizati rolul funcției s signal. 
17). Descrieţi acțiunile funcţiei s. ; signal). pi 
18). Daţi o implementare C pentru functia s signal): 
19). Cum se asigură excluderea mutuală prin mecanismul 

semäjoar elor? 
. Ce avantaje prezintă mecanismul. semafoareloi? 
. Ce dezavantaje prezintă mecanismul semafoarelor?: 


6.2.4. Excluderea mutuală prin blocuri 
SO resursă 


Un neajuns al semafoarelor, aparent minor, dar în practică 
surs a numeroase erori, greu de depistat în aplicațiile 
complexe, este că nu oferă, la nivelul execuției programelor, 
garanția delimitării corecte a secțiunilor critice prin funcțiile 
_s_wait) şi _s_signal(). 


De exemplu, o dublă eroare de programare ca cea surprinsă 
în figura 6.2.4_1 nu va fi semnalată nici la compilare, nici în 
timpul rulării, conducând-la un comportament al programului 
greu de explicat. 
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în taskul ALFA în taskul BETA 


_s_wait(a, to_alfa); _s_wait (b, to_beta); 


< secțiune < secțiune 
critică critică 


_S_signal (a); 


_s_signal (b); 


Fig. 6.2.4_1. Exemplu de utilizare greşită 
a funcțiilor s_wait () şi s_signal Q. 


Pentru a se putea semnala în timpul rulării existența unor 
situații ca cea din figura 6.2.4_1, ar fi necesar ca fiecare 
semafor să înglobeze încă o componentă, în care să se 
înregistreze indexul taskului care, executând primitiva P asupra 
semaforului, reuşeşte să-şi inițieze secțiunea critică. Dacă 
s-ar dispune de o asemenea componentă, atunci ea ar putea fi 
consultată de primitiva V şi folosită pentru condiționarea 
execuției ei propriu-zise de concordanța dintre indexul taskului 
în care ea este programată și valoarea înregistrată în această 
componentă. 


Se spune că taskul al cărui index este înregistrat în această 
nouă componentă a tipului definit SEMAPHORE este 
proprietarul curent al resursei la care se referă secțiunea critică 
în cauză. 


Un semafor care asigură înregistrarea proprietarului curent 
al resursei căreia el îi corespunde se numeşte bloc resursă. 


Evident, valoarea inițială a contorului unui semafor 
transformat într-un bloc resursă nu poate fi decât 1. 
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peria a aia ela nt at ANANAS 


Perechea de primitive P şi V aferente unui bloc resursă este 
desemnată prin termenul gestionar de resursă. 


În vederea implementării mecanismului de excludere 
mutuală prin blocuri resursă, se defineşte tipul de dată 
RESOURCE, ca o structură cuprinzând: 

- un tablou de tipul uschar cu MAX TSK elemente, 
dedicat a servi drept coadă a blocului resursă; fie 
coada[] numele acestui tablou; 

- o variabilă de tipul skori, reprezentând contorul 
blocului resursă; fie contor numele acestei variabile; 

- o variabilă de tipul pointer către un caracter fără 
semn, având rolul de a asista intrarea în coada 
blocului resursă; fie pi numele acestei variabile; 

- o variabilă de tipul pointer către un caracter fără 
semn, având rolul de a asista ieşirea din coada blocului 
resursă; fie pe numele acestei variabile; 

- o variabilă de tipul uschar, dedicată înregistrării 
indexului proprietarului curent al resursei căreia îi 
corespunde blocul resursă; fie propr numele acestei 
variabile. 


Tipul de dată RESOURCE se va introduce, deci, printr-o 
declaraţie de forma: 


typedef struct 
short contor; 
uschar coada [MAX_TSK] ; 
uschar *pi; 
uschar *pe; 
uschar propr; 
RESOURCE ; 


Fig. 6.2.4 2. Declararea tipului de dată RESOURCE. 


Este firesc ca toate blocurile resursă disponibile într-un 
sistem să fie grupate sub forma unui tablou. Dacă admitem că 
numărul maxim de blocuri resursă este MAĂ_RES, atunci acest 
tablou -fie _res// numele lui- va fi declarat astfel: 
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RESOURCE _res[MAX_RES] ; 


Fig. 6.2.4_3. Declararea tabloului de blocuri resursă _res/7. 


Este de subînţeles că declaraţia de mai sus trebuie să apară în 
afara oricăror acolade, fiind necesar ca tabloul _res// să aibă 
statut de variabilă globală, deci: să fie cu locare statică în 
memorie. În această situație, un bloc resursă concret va fi 
exploatat cu ajutorul indicelui său în cadrul tabloului de blocuri 
resursă, introducând câte un identificator pentru fiecare indice. 


Ca şi semafoarele, blocurile resursă se exploatează doar prin 
intermediul unor funcții ale executivului. Aceste funcții sunt: 


void _r_init (void) 
/* iniţializează tabloul de blocuri resursă, */ 
/* prin atribuirea valorii NULL */ 
/* componentelor pi ale elementelor sale */ 


void _r_create(uschar *residadr) 
/* alocă un element al tabloului res//, */ 
/* atribuie componentei contor a elementului */ 
/* alocat valoarea 1 şi furnizează indicele */ 
/* acestui element în variabila pointată de residady 


void_r_destroy (usshori resid) 

dezalocă elementul tabloului _res/] cu indicele resid, */ / 
repunându-l la dispoziția funcției _r_creat () */ 

(se continuă) 


Fig. 6.2.4_4. Funcţiile de exploatare 
a blocurilor resursă -partea întâi- 
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(continuare) 


usshort _r_wait (usshort resid, usint timeout) 
/* efectuează operaţia P asupra blocului resursă */ 
/* cu indicele resid şi reţine */ 
/* valoarea argumentului fimeout ca timp */ 
/* limită în care taskul curent poate */ 
/* rămâne blocat la blocul resursă; * 
/* înregistrează în câmpul propr 


/* al blocului resursă resid */ 
/* valoarea indexului taskului curent, */ 
/* când acesta este autorizat să-și continue rularea */ 


i void _r_ signal (uschar resid) 
/* efectuează operaţia V asupra blocului resursă */ 

/* cu indicele resid, dacă proprictarul */ 
i /* resursei corespondente acestuia este taskul curent, */ 
i /* altfel semnalează eroare */ 
li 


Fig, 6.2.4_4. Funcţiile de exploatare 
a blocurilor resursă -partea a doua-. 


Funcţiile _r_iniz(), __r_create() şi_r_destroy() 
Aceste funcţii sunt identice cu sau extrem de puţin diferite 


(_r_creat()) de corespondentele lor din cazul semafoarelor: 
_$_init(),_s_create() şi _s_destroy(). 


Funcţia _r_wair() 


Tot ce s-a menţionat la prezentarea funcţiei _s_waiz() este 
valabil, cu adaptările de rigoare, şi pentru funcţia r wait). În 
plus, în finalul funcţiei _r wait, înaintea autorizării 
întreruperilor, se impune ca ea să înregistreze indexul taskului 
curent în câmpul propr al blocului resursă cu indicele resid. 
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Textul C al funcției _r wair() este prezentat în figura 
6.24 5. 


1 void _r wait(uschar resid, usint timeout) 4 
2 RESOURCE *r; i 
3 _lock (); 

4 r=& res[resid]; 

5 if (--r->contor<0) | 

6 *r->pi=_tsk_crt; 

7 if (r->pi==& (r->coada [MAX _TSK-1]) ) 1 

8 r->pi=& (r->coada [0]) ; 

3 } 
10 else[ 

11 (x->pi) tt: 

12 ) 

13 _sleep (timeout) ; 

14 ) 
15 r->propr=_tsk_crt; | 
16 _unlock () ; i 


17 ) i 


Fig. 6.2.4_5. Textul funcției _r_wair(). 


Funcţia _r_signal() 


Funcţia _r_signal() trebuic să debuteze cu consultarea 
câmpului propr al blocului resursă cu indicele resid. Dacă 
valoarea înscrisă în acest câmp nu coincide cu indexul taskului 
curent, acțiunea funcţiei _r_sienal() se limitează la generarea 
unui mesaj de eroare. Altfel, funcția _r_signal() efectuează, în 
continuare, operaţiile care au fost prezentate la funcția 
_s_signal(), cu adaptările de rigoare. 


Textul C al funcţiei _r_sienal() este redat în figura 6.2.4_6. 
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void _r signal (uschar resid) ( 


d 
2 RESOURCE *r; 
3 uschar k; 
4 _lock (); 
5 r=&_res[resid]; 
6 it (r->propr==_tsk_ cert) [ 
7 if (++r->contor<=0) { 
8 r->propr=MAX TSK; 
9 k=* (r->pe) ; = 
10 * (r->pe)=MAX_TSK; 
11 if (r->pe==& (r->coada [MAX_TSK-1]) ) 4 
12 r->pe=& (r->coada [0]) ; 
13 ) 
14 elseţ 
15 (r->pe) ++; 
16 li 
17 _wakeup (k) ; 
19 ) 
20 else 
21 abort ("Eroare in taskul $%2d: Tentativa | 
22 ilegala de eliberare a resursei $2d 
23 (proprietar este taskul $2d)!", 
24 _tsk_cert, resid, _reslresid] .propr); 
25 } 


26 _unlock () ; 


Fig. 6.2.4_6. Textul funcțici r_signal/(). 
ÎNTREBĂRI: 


1). Definiți noțiunea de bloc resursă... 
2). Ce este, în plan practic, un bloc vesur-să? 
'3). În ce consistă mecanismul blocurilor resursă? 
4). Precizaţi rolul functiei: r înit(). 
5). Descrieţi acțiunile funeţiei :-r-InitQ). 
6). Daţi o implementare C pentru functia r initQ). 
7). Precizaţi rolul funcției -r create). 
8). Descrieti acțiunile funcției. r creat 0; 
9). Daţi o implementare C pentru funcția. r -createQ. 
10). Precizaţi rolul funcției r destroyQ). ; 
11). Descrieti actiunile funcţiei “i. destr'oy). 


12). Daţi o implementare C pentru Jiunctia r- destroy). 
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13), 
14). 
15). 
16). 
17). 
15). 
19). 


20). 


21). 


Preċizați rolul functiei r wait. 

Descrieti acțiunile funcției._r--wait). 

Daţi o implementare C pentru. funcția r- wait: 
Pretizăţi rolul funcției r_sienalO. 

Descrieţi acțiunile funcţiei... signal): 

Daţi o implementare C pentru functia -F "signal. 
Cum. se asigură excluderea mutuală prin 
mecanismul blocurilor resursă? 

Ce avantaje prezintă mecanismul blocurilor 
resursă? 

Ce dezavantaje prezintă mecanismul blocurilor 
resursă? 
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REZUMAT 
„Se numeste 1esursă orice entitate de, care are nevoie uñ task 
pentr ua putea fi rulat: 


Resursele de natură materială se numesc resurse: materiale, 
iar resursele de natra iogica SE numesc resurse logice. 


Se numeşte resursă locală o resursă accesabilă dour de 
către un 1 Singur task. oiu 


Se numeste resursă comună 0 resursă accesabilă ae. către 
cel puțin două tashkuri. 


Se numeşte resursă critică o resur. 
doar o sesiune. de lucru: a d 
moment. 


resursă comună care admite ca "n 
să fie în derulare la un moment. î 


Se numeşte resursă. reentrantă o. resursă. comună care 
admite ca oricâte sesiuni de lucru asupra eisa a fie î în. derulare 
laun moment. 


Se numeşte resursă banalizată o resursă existentă. în. mai 
multe exemplare. identice, capabile oricare: să satisfacă. la un 
moment, în aceleaşi condiții, o cerere dată. 


f 


f i nea eee PR E atit 4 

| "Se numeşi secțiune critică o portiune. e program prin care 

se realizează o sesiune de lucru « asupra unei. vesul, A 
lizează o s ASUPrA UNELFESUTSE: CKI 


Se numeşte secțiune de partaj e) portiune de program: prin 
care se realizează. o sesiune da lucru asupra inei resurse 
partajabile. i ; 
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Ítr- -un sistem a multitasking, p OL. - onmi în Hong 
situatii: 5 : 
1). atunci. când, în timp ce un task a pătr uns într- -0. secuime 

critică a sa col 'espunzătoare unei resurse critice şi încă nu 

“a depăşit-o, un alt task ajunge pe punctul de a intra în 

“pi opria-i. secțiune critică refer 'itoare la acceaşi resursă. 


2). atunci când în timp ce "n" taskuri. au păti: uns în secțiunile 
lor de partaj corespunzătoare. unei resurse par tajabile cu 
“n? ” puncte de acces, fără a le depăşi, un al n+1 -lea task 
"ajunge pe punctul de a intra în pri opria-i secțiune de partaj 
peer iloare la aceeaşi resursă. i 


Se numeşte, excludere mutuală excluderea de. către un task 
itică referitoare la o. resursă a 
ea pauni i ms ecțiuni critice care 


zecanismul. blocurilor resursă. 


$ Mecanismul dezactivării întreruperilor consistă. în două 
macroinstrucpii: ; îi 


lock). 
/* salvează starea curentă a fanionului */ 
de activare /. dezactivarea intrer uperilor */ 
Aşi apoi dezactivează. într cupei ile */ 


unlock) : 
/* reface starea fanionului */ 
/* de activare / dezactivarea întreruperilor */.. 
pe, aşa cum a fost găsită de lock 2 
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Exchiderea mutuală prin mecanismul dezactivării 
întreri uperilor: se asieură incepând sectiunea cri itică cu lock0 
şi. încheind -0 cu unlock. i ; 


Mecanismul dezactivării intrer uperilor pi ezintă avantajul că 
este simplu dezavantajul că poa caziona scăpar CA unor 
fnireruper : i 

[ è Mecanismul fanioanelor pasive « are la bază conceptul de 
i fanion de excluziune . 


N 


Se EN fanion de excluziune + 9 variabilă booleanā cu 

valoarea. inițială. “o, apra căreia se pol. efectua, două 
Oper ați: i 

- 0 Oper: atie indivizibilă a testare esi fori jare. k 

„ AndSei); PD a 

2.0 Opa apie or jare la 


T asupr a pa de. € 
Aşi, dacă acesta indică 
/ * atunci inițiază secțiunea ci 
sa A ali (fel reia totul de la capăt a 


a ,_signal0 
~ t efectuează operația RESet */ 
/* as asupr a fanionului de excluziune anvizajat, */. 
/* marcând, astfel; părăsirea secțiunii critice. */ 


Excluderea mutuală prin. meçanismul fanioanelor pasive se 
asigură începând secțiunea critică cu a wai şi încheind- O 
cu a signal. : 


Mecanismul , fanivanelor pasive prezintă avantajul că este 


simplu şi dezavantajele că iroseste timp-procesor (incumbând 
— active) şi i face posibilă apariția in interi blocajelor. i 
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Se numeşte fanion activ un fanion dè excluziune. aflat în 
postura de element central al unui mecanism capabil să 
provoace pi ocesul de comutare. aa 


“În plan “practic, un Janion activ este o structură definită 
astfel: 


typedef struct. 
uschar fan; 
uschar coada [MAX TSK]; 

< uschar *pie; 


in. sa A de si ucluri Hie Aa MAx. FLG]; 
"un. set de cinci funcții care au monopolul operärii 
asupra a structurilor FLAG: 


WA inito 


A+ mjali aa tabloul de Janioane “y 


F Create) 


/* creează un fanion: */ 


fi destroyQ 
4 disiruge. un fanion 2 
be continuă) 
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(continuare) sa 
: i f wait) 
/* inițiază o secțiune critică imediat sau, */ 
dacă este cazul, după o aşteptare pasivă. */ 
; -f.sional) 
Z5 semnalează încheierea unei secțiuni critice “ 
"/* deblocând toate taskurile */ 
7 aflate în aşteptarea acestui fapt WA 


Excluderea 1 mutuala prin mecanismul fanioanelor active se 
asigură începând. secțiunea critică cu f. wait ji încheind cu 


SA signal). 


cori espunzătoa 
Dezavantajul 


$ Mecanismul. semafoarelor. are. 
semafor, -o 


„Se numeşte semafor un ansamblu format. dintr-o variabilă 
întreagă I, inițializată la o valoare nenegativä, şi o coadă de 
aşteptare C şi care este supus la două operații. 

1). operatia P, în cadr ul căreia: 

e sedeer ementează variabila Icuo uniraie 
e se testează variabila I şi dacă. T>=0, atunci se lasă i în 
rulare taskul curent, iar altfel -dacă I<0-, se scoate 
. din rulare laskul. curent, se blochează şi se înscrie. în 
" coada C, iar apoi se pr. Ovoacă. un proces dè comutare 


pentru ini roducere ea în rulare a unui alt task. 
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se o incrementează variabila. I cuo unitate 
se testează variabila I şi dacă 1>0, atunci se să 


în rulare taskul curent, iar altfel -dacă I<=0- 


capul cozii C, 


se deblochează taskul € , 
-introduce în rândul 


_ (continuare) - 

; Salt) 

/* iniţiază o secțiune critică imediat sau, */ 
4 dacă esie cazul, după 9 aşteptare e pasivă y 


s. sianal() i 
> X semnalează încheierea unei secțiuni critice “o 
Ž deblocând taskul aflat cel mai de demult */ 
Pa în aşteptarea acestui fapt */ 


Be dopo mutuala prin mecanismul emare. se 
asigură începând — critică cu s aie) şi încheincdo. 
cus raid), o i 


canismul. blo 
Cavereura : 
; Sx numeyte bloe 
posibilitatea 2 


A typedef struct. 
"short contor; Š it 
uschar coada [MAX Is); Fi 

: „uschar sepia 


e uscha propr 
F RESOURCE; 
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- ampule contor, coada), pi şi pe au , aceleaşi semnificatii 
ca şi la structura SEMAPHORE : 

- câmpul propr reprezintă var iabila în care se imegisirează 
“indexul. taskului pus în asociere la un moment, cu blocul 


1). Ce se înțelese prin resursă? 
2) Ce sunt resursele materiale? 
3). Ce suni resursele logice? 
4). Ce se înțelege prin resursă locală? . 
5). Ce se înțelege prin resursă comună? 
6). Ce se înțelege prin resursă critică? 
7) Ce se înțelege. prin resursă.  Pertojabila cu 
puncte d de acces? 
Ce se înelege prin resursă reentrant: ?; 
9). Ce se înțelege pri in resursă banalizată? 
l 0). Cea se înțelege prin secțiune critică 


Fi ESUE să. Fi especiiv. 3 


Mecanismul blocurilor FESUrSĂ consistă i în: 
ə un tablou de sti ucturi RESOURCE., _res|MAX. RES); 
e un ser de cinci funcții care au monopolul operării 

| asupra a Structuri ilor RESOURCE: 


PR 
aM: 


se 


12), În ce. situații pot a 
e multitasking? 
13). Ce se înţeleg, prin 
14). Care sui 
pu ï 


; 19), e a maăcroinstructiei flo 

20). Descrieţi acțiunile macroinsirucției_ unlock). Sod 
21). Dați o implementare pentu harena 
unlock). -o o 
22). Cum se asigură excluderea mutuală prinț 
: mecanismul dezactivării întreruperilor?. o 

23) Ce “avantaje prezintă mecanismul. dezactivării 
= ftre -uperilor?. o o i ~ o 
3 enai prezintă mecanismul dezactivării 


0 ei a N E EA EEN RAEES 


/* de. către taskul care a anlamer-o, 
~“ deblocând taskul aflat cel mai de demult Y 
Aà în așteptarea acestui i fapt w 


resu ä „prezintă : ca. avantaj 
faptul. că nu se poate aplica î în 
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27) Precizați rolul macroinstrucției 
28). Deserieţi acțiunile macroinstrucției a voit). . 
29). Dai 0. implementare Po macroinstrucjia 
= awai) : 
D Brecizați rolul macroinsirucjiei _ a , signalQ. 
3D. Descrieți acțiunile macr oinstrucției a inalo 
32. Dai o. „implementare peniru macroinstrucția 
a ,signal0. n 
33). “Cum se asigură excluderea. mutuală prin 
“mecanismul. fanioanelor pasive? 
4). Ce avantaje r necanismul Janioanelor 
pasive? o : 
„Ce. dezavantaje pri ezintă mecanismul fenioanelor 
pasive? î CC 
Definiţi fo liuea de fanion activ. n 
Ce este, în plan, practic, un fanion activ? 
consistă mecanism  fanioanelor active? 


e functiei „fi inito. 
eC. Dent u pe _finitỌ. 


%6 Descrieți a funcției S destroy). : . 
47). Daţi o implementare C, pentru funcția fi oul 


| a ( Size fineţe pt a 
. Precizați rolul funcției _f_signal(). 
7  Descriefi. acțiunile funcției. f semnal... 
. Dați implementare C peniru functi a F enal 
Cum. se asigură “excluderea. mutuală prin 
= mecanismul fanioanelor. active? o 
55). Ce avantaje prezintă mecanismul fanioanelor 
o ative? 
Ce. “dezav ntaje. prezintă. mecanismul fanioanelor 
active? : 
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CNA AO Oe A A e UA A A a ti a Aa 


37), 
58). 
59). 


60). 


g 
62), 
63), 
64). 
65). 
66). 
67), 


68). 


69). 


70). 
71). 


72). 
73). 


74). 


75). 


76). 
77), 
78). 
79). 
80). 


s). 


82). 
83). 


84). 
85). 
50). 
87). 
85). 
89). 


90). 
91). 


92). 

93), 
94). 

95). 


„Definiţi notiunea de semafor, 
Ce este, în plan practie, un semafor: A 


“Descrieți acțiunile funcției .r. înitQ). 


Precizaţi rolul funcției _r. - dostroy0. 
“Descrieţi actiunile funcţiei E . destroyQ. 


"Precizaţi rolul funcției _ r waitỌ: 


În ce consistă mecanismul semafoavelor 

Precizaţi rolul funcției . s. int). 

Descrieţi acțiunile funcției s$ ;_init0. 

Daţi o implementari e C pentru funcția, -$ ini). 
Precizai rolul funcției S..create(). 

Descrieți acțiunile funcției _s_creat Q. 

Daţi o implementare C pentru funcția. s- create: 
Precizaţi rolul funcţiei __S._destroyQ). 

Descrieţi acțiunile funcției -s__destroyQ: 

Daţi o implementare C pentru functia S- destroy. 
Precizaţi rolul. “funcției. S. waiQ. 

'Descrieţi acțiunile funcției. s wailQ. 

Daţi o implementare C pentru functia s wato. 
Precizaji rolul funcției. s. signal). 
Desciiieţi acțiunile fimcției S_sienal0. i 
Daţi o implementate C pentru funia. în) seral). 
Cum se asigură. excluderea. a 
mecanismul semafoarelor 


Ce este, în plan practic, un bloc ı resursă 
În ce consistă mecanismul blocurilo 
Precizați rolul funcției _r_init0). 


Daţi o implementare C pentru funcția rin). 
Precizaţi rolul. funcției Tcr cate). 

Descrieţi acțiunile funcției _ create). 

Daţi o implementare C pentru funcţia T. er cate(). 


Dati o implementare C pentru functia t. destroy). 


Descrieţi actiunile fimeției _.r wuit). 

Daţi o implementare C pentru funcția t. wait). 
Precizaţi rolul funcției ..r. sisnal(). 

Descrieţi acțiunile funcției._r_sional). ii 
Daţi o implementare C peniru funcjia. r. signalo. 
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96). se asigură excluderea mutuală prin 
i nismul blocurilor resursă? — 
97). Ce avantaje prezintă mecanismul. 
resursă ; a 
95). Ce dezavantaje prezintă mecanismul blocurilor! 
resursă? o 


blocurilor 
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a iii A A e se N au e e 


7 
SINCRONIZAREA TASKURILOR 


7.1. Preliminarii 


/ Un task al unei aplicații cuprinde, în cea mai mare parte a sa, 


„ activități care se pot derula independent și deci în paralel față 


de cele ale altor taskuri. Totuşi, în anumite puncte ale lor, 
Y : O, i r : : R 
taskurile trebuie să se supună unor relații de ordine, menite să 
asigure o corelare temporală a activităților lor, conformă cu 
cerințele aplicației. 


De exemplu, într-o aplicație de conducere a unui proces, un 
task efectuează achiziția datelor, depunându-le într-un tampon, 
iar alte taskuri, cum sunt: taskul de supraveghere, taskul de 
reglare şi taskul de protocolare prelucrează aceste date, fiecare 
conform misiunii pe care o are. Este evident că ultimele trei 
taskuri nu-și pot începe o sesiune de lucru decât după ce taskul 
de achiziție termină de depus în tampon toate datele pe care le 
are de prelevat din proces. Odată petrecut acest lucru, taskurile 
menţionate îşi preiau datele din tampon, desigur, în cadrul unor 
secțiuni critice, şi apoi îşi continuă activitățile specifice, 
independent unele de altele. 


Pe de altă parte, din ansamblul activităților pe care le 
comportă o aplicaţie, unele sunt legate de anumite evenimente 
exterioare, semnalate, de regulă, prin întreruperi. În exemplul 
de mai sus, taskul de achiziție prelevează datele din proces 
doar la momente de timp dictate de ceasul de timp real, cu o 
periodicitate stabilită în conformitate cu dinamica procesului și 
cu performanțele ce se impun conducerii acestuia. 
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Punerea taskunlur într-o anumită relaţie temporală unele cu 
altele sau cu diferite evenimente externe poartă denumirea de 


sincronizare a laskurilor. 


Sincronizarea taskurilor se realizează fie prin acţiuni de 
activare / dezactivare, fie prin acțiuni de blocare / deblocare. 


Cererile de activare, ca şi de deblocare a taskurilor, pot fi 


memorate sau nememorate. 


O cerere nememorată este pierdută dacă taskul căreia îi este 
adresată nu o aşteaptă Concret: o cerere de activare 
nememorată, adresată unui task aflat în starea creat, îşi exercită 
acțiunea, putându-se spune că taskul o aştepta, dar rămâne fără 
efect dacă este adresată unui task deja activ, adică aflat în una 
dintre stările gata, în execuţie sau blocat, o cerere de deblocare 
nememorată, adresată unui task aflat în starea blocat, îşi 
exercită acțiunea, dar rămâne fără efect dacă este adresată unui 
task aflat în una dintre stările: creat, gata sau în execuție. 


Cererile memorate sunt reţinute în evidență, cumulativ, şi își 
exercită acțiunea cu întârziere, până la onorarea tuturor, de 
îndată ce taskul căruia îi sunt adresate ajunge în starea creat, 
când este vorba despre activare, respectiv în starea blocat, când 
este vorba despre deblocare. 


In cele ce urmează, se vor aborda doar tehnici de realizare a 
sincronizării prin blocare / deblocare, nu şi prin activare / 


dezactivare. 


Sincronizarea este directă atunci când vizează în mod 
explicit unul sau mai multe taskuri. 


Sincronizarea este indirectă atunci când vizează unul sau 
mai multe taskuri prin intermediul unui mecanism care doar el 
le cunoaşte în mod concret. 
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Unul dintre termenii cheie aferenți problemei sincronizării 
este acela de eveniment. Se numeşte eveniment un fapt asociat 
unei mărimi booleene, care ia valoarea logică "1", dacă faptul 
este produs, şi valoarea logică "0", dacă faptul nu este produs. 


Evenimentele pot fi concrete sau abstracte. 


Un eveniment este concret dacă este legat de o operaţie ce se 
desfăşoară în afara programului. Evenimente concrete sunt, de 
exemplu: terminarea unei operaţii de intrare / ieşire, apariția 
unei întreruperi de la ceasul de timp real, etc. 


Un eveniment este abstract dacă este legat de o operaţie 
intrinsecă programului. Eveniment abstract este, de exemplu, 
terminarea operaţiei de tratare preliminară a datelor prelevate 
dintr-un proces, 


Un eveniment care deja s-a produs se numește eveniment 
perimat. 


Un eveniment care încă nu s-a produs se numește eveniment 
neperimat, 


Dacă două evenimente au loc în același moment de timp, ele 
se numesc simultane. 


Dacă două evenimente au loc în acelaşi interval de timp, ele 
se numesc concurente. 


Când momentele de producere a unor evenimente se află 
într-o relație temporală bine precizată, predictibilă, 
respectivele evenimente sunt, între ele, sincrone. 


Când momentele de producere a unor evenimente nu se află 
într-o relație temporală bine.precizată, predictibilă, respectivele 
evenimente sunt, între ele, asincrone. 
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ÎNTREBĂRI: 


1): Ce se o imjelege prin siner. onizare a taskurilor? 
2). Când se spune că sincronizarea este directă? 
3): Când se spune că sincronizarea este indiri ectă?. 
4). Ce se înțelege. prin cereri de sincronizare 
" nememorate?. : a s 
5). Ce se înțelege. „prin cereri de sincronizare! 
` memorate? 
6). Ce se înțelege prin eveniment? 
7). Cese înțelege prin eveniment concret? 
8). Ce se înțelege prin eveniment abstract? 
.: Ce se înțelege prin eveniment perimat? 
Ce înțelege prin eveniment neperi imat? 
Cese înțelege prin evenimente simultane? 
se înțelege prin evenimente concurente? 
de se în elege | prin evenimente sincrone? 
Ga. se elege prin evenimente asincrone? 


7.2. Mecanisme de sincronizare 
directă 


7.2.1. Sincronizarea prin funcțiile 
_sleep() şi _wakeup() 


Aceste funcţii pot servi în scopuri de sincronizare astfel: 
Când un task nu-și poate continua rularea, necesitând 
producerea unui eveniment, el se adoarme, executând funcția 

_sleepQ. Când evenimentul respectiv se produce, atunci într-o 
Yutină de deservire de întrerupere -dacă evenimentul este 
concret- sau într-un alt task -dacă evenimentul este abstract-, 
se ‘execută funcția _wakeup() cu referire la taskul care s-a 
adormit. 
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oii a 930 AO) 6 di a A ESA 04 a OA ada 


Acest mecanism are avantajul simplităţii şi consumului 
redus de timp procesor. El este, însă, anevoios de aplicat în 
rezolvarea unor probleme de sincronizare complexe. 


7.3. Mecanisme de sincronizare 
indirectă 


7.3.1. Sincronizarea prin semafoare 


Mecanismul semafoarelor este adecvat soluționării a 
numeroase probleme de sincronizăre. Vom ilustra aplicarea lui, 
considerând următoarele cazuri de studiu: 


Cazul de studiu | 


Intr-o aplicaţie se cere ca două taskuri, A și B, să procedeze 
la câte o rulare completă a lor, de fiecare dată când se produce 
un eveniment concret e [20]. 


Se poate asigura acest lucru astfel: Se pune la dispoziția 
fiecăruia dintre taskurile A şi B câte un semafor, cu 
contorul inițializat la zero. Fie e, respectiv b identificatorii 
asociați acestor semafoare, identificatori ce reprezintă, 
reamintim, indicii semafoarelor în tabloul de semafoare. Se 
prevede în rutina de deservire a întreruperii corespunzătoare 
evenimentului concret în cauză câte o funcție _s signal) 
pentru fiecare dintre aceste semafoare. În fiecare dintre cele 
două taskuri, în punctele potrivite, se programează execuţia 
funcției _s_wair(), cu referire la semaforul aferent. 


Figura 7.3.1_1 conţine o reprezentare sugestivă a celor 
menţionate. 
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TASEK_AQ întrerupere 
£ (e) 
PI i ae / 
_s_wait(a,0); RUTINĂ DESERVIRE */ 
ÎNTRERUPERE */ 
at / 
ii 
_s_signal(a); 
TASK_BO _s_signal(b); 
í 3 
_s_wait(b,0); 
îi PRI 
în 
J 


Fig. 7.3.1_1. Sincronizarea taskurilor A şi B 
cu evenimentul legat de întreruperea e. 


Evident, mai multe situaţii sunt posibile în cadrul cazului de 
studiu considerat. Următoarele două sunt, însă, reprezentative: 


1). Taskurile A şi B execută funcţiile _s_wait(a,0), 
respectiv  _s_wait(b,0) înainte de producerea 
evenimentului e. În această situație, contoarele 
semafoarelor a şi b vor ajunge la valoarea -1 şi 
taskurile se vor bloca: Abia după ce evenimentul e are 
loc, când contoarele semafoarelor ajung la valoarea 0 ca 
urmare a execuției. funcțiilor _s_sigaal(a), respectiv 
_s signal(b) în rutina de deservire a întreruperii 
corespunzătoare evenimentului, cele două taskuri pot 
intra în rulare. 
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2). Evenimentul e se produce înaintea execuției funcțiilor 
_s_wait(a,0), respectiv wait(b,0) în cele două 
taskuri. În această situație, execuția funcţiilor 
_s_signal(a) şi _s_signal(b) în rutina de tratare a 
întreruperii corespunzătoare evenimentului e va 
determina ajungerea contoarelor celor două semafoare la 
valoarea 1. În consecință, când taskurile A şi B vor fi în 
stadiul de a executa funcţiile _s_wait(a,0), respectiv 
_s_wait(b,0), ele nu se vor mai bloca, comportându-se, 
astfel, în mod corespunzător, vis-a-vis de faptul că 
evenimentul e s-a produs. 


5 


Rezultă, aşadar, că, prin mecanismul semafoarelor, se 
asigură inclusiv memorarea evenimentelor. Într-adevăr, dacă 
situația 2) s-ar ivi de n ori succesiv, fără ca taskurile A şi B 
să execute vreodată funcţiile _s_wait(a,0), respectiv 
_s_wait(b,0), contoarele semafoarelor ar ajunge la valoarea 7 
şi ar asigura ca, până la urmă, taskurile A şi B să fie rulate de 
nori. 


Figura 7.3.]_2 redă frânturi semnificative din programul 
corespunzător cazului de studiu considerat. 


i 1 r i 
i 2 uschar a,b; i 
i 3 TASK init() 
| a i 
H 5 Tr 
6 _s_creat (&a,0); 
7 _s_creat (&b,0); 
8 Te 
9 } 
10 void far interrupt rutina eveniment _e() 
11 4 
12 rea 
13 _S_signal (a); 
14 /* semnalează taskului A */ 
15 /* producerea evenimentului e */ 


(se continuă) 


Fig. 7.3.1_2. Exemplu de sincronizare prin semafoare -partea întâi. 


163 


CAP. 7. SINCRONIZAREA TASKURILOR 


(continuare) 
16 s_signal (b); 

17 7* semnalează taskului B */ 
18 /* producerea evenimentului e */ 
19 ka 

20 /* achită întreruperea */ 

21 3} 

22 TASK A() 

23 4 

24 ESK 

25 _s_ wait (a,0); 

26 BA 

27 9} 

28 TASKB () 

29 { 

30 SAA 

31 _s_wait (b,0); 

32 pei 

33 ) 


Fig. 7.3.1_2, Exemplu de sincronizare prin semafoare -partea a doua. 


Cazul de studiu II 


Într-o aplicaţie, mai multe taskuri depun date de un anumit 
format într-o zonă tampon, pentru ca din aceasta, ele să fie 
extrase de alte taskuri, în scopul prelucrării lor. Primele taskuri 
se numesc producătoare, iar celelalte -consumatoare. În 
tampon pot fi cumulate maximum n date. La un moment, doar 
un singur task poate accesa zona tampon [4]. 


Se pune întrebarea: cum se poate asigura sincronizarea 
taskurilor care acționează asupra zonei tampon? 


Analizând acest caz, concluzionăm că el comportă două 


probleme: 
1). problema accesării zonei tampon de către un singur task 
la un moment; 
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2). problema  sincronizării propriu-zise a  taskurilor 
consumatoare cu taskurile producătoare, constând în 
autorizarea  taskurilor consumatoare de a citi zona 
tampon doar dacă ea nu este vidă și pentru fiecare dată 
aflată în ea, o dată şi numai o dată, respectiv în 
autorizarea taskurilor producătoare de a depune date în 
zona tampon doar dacă în aceasta mai există loc. 


Prima problemă se poate rezolva prin utilizarea unui 
semafor de excluziune asociat zonei tampon. Fie s/ 
identificatorul acestui semafor. Evident, el se va crea cu 
contorul initializat la valoarea 1. 


Fiecare proces, producător sau consumator, va accesa zona 
tampon printr-o secţiune critică delimitată de funcţiile 
_S_wail(s1,0), respectiv _s_sienal(s1). 


A doua problemă se poate rezolva prin utilizarea a două 
semafoare. Fie s2, respectiv s3 identificatorii acestor 
semafoare. 


Semaforul s2 se va crea cu contorul inițializat la valoarea 0. 
Toate taskurile producătoare vor executa funcţia _s_signal(s2) 
după fiecare depunere a unei date în zona tampon. 
Toate taskurile consumatoare vor executa  fincția 
_s_wait(52,0) înaintea fiecărei extrageri a unei date din zona 
tampon sau, mai corect spus, în momentul în care sunt apte să 
extragă o dată din zona tampon. În acest fel, valoarea 
contorului semaforului s2 va arăta: 

- dacă este pozitivă, câte date se află depuse în zona 
tampon 

- dacă este negativă, câte taskuri consumatoare au găsit 
zona tampon vidă, fiind nesatisfăcute 

- dacă este nulă, că nu există nici o dată în zona tampon 
şi că nici un task consumator nu este nesatisfăcut. 
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Semaforul s3 se va crea cu contorul inițializat la valoarea 7. 
Toate taskurile producătoare vor executa funcția _s_wait(s3,0) 
înaintea fiecărei depuneri a unei date în zona tampon, 
procedând la depunerea efectivă doar când în această zonă 
mai există spaţiu liber. Toate taskurile consumatoare vor 
executa funcția _s signal(s3) după fiecare extragere a unei date 
din zona tampon. În acest fel, valoarea contorului semaforului 
s3 va arăta: 

- dacă este pozitivă, câte date mai încap în zona tampon 

- dacă este negativă, câte taskuri producătoare au găsit 
zona tampon plină, blocându-se în aşteptarea creerii 
unui spaţiu liber în cadrul ei 

- dacă este nulă, că zona tampon este plină, dar nici un 
task producător nu a ajuns să fie blocat din această 
cauză. 


Sintetizând, rezultă că sincronizarea taskurilor ce acționează 
asupra unei zone tampon se asigură instituind pentru 
producători şi consumatori procedurile prezentate în figura 
7.3.1_4. Se precizează că aceste proceduri constituie ceea ce se 
cheamă modelul producătorilor şi al consumatorilor 


| semaforul s7 se creează cu contorul inițializat la 1 

| /* semaforul s2 se creează cu contorul inițializat la 0 */ 
i /* sematoiul s3 se creează cu contorul iniţializat la n */ 
| 


Pre e e e ee de e e de e e e e ee e e e e e eh de e Ae e e e e e e e e He de de eke f 
pe PROCEDURA PRODUCĂTORILOR */ |} 
Î pe deh e e de e E EEEEE EEE EEE EES EAE RR E RR RE kk / i 
| 1. execută _5 wait (s3,0); i 
/* aşteaptă la semaforul s3 până când acesta */ 
/* garantează că zona tampon ńu este plină */ 
2. execută _s wait (51,0); 
/* aşteaptă la semaforul s7 până când acesta */ 
/* garantează că nici un task nu execută o*/ 
/* secţiune critică de accesare a zonei tampon */ 
depune o dată în zona tampon; 
execută _s signal (s2); 
/* semnalează că în zona tampon */ 
/*a fost depusă o (nouă) dată */ 
5. execută _s signal (s1); 
/* semnalează că taskul curent şi-a încheiat */ 
/* secţiunea critică de accesare a zonei tampon */ 


A Ww 


Fig. 7.3.1_3 . Modelu! producătorilor și a! consumatorilor 
-procedura producătorilor 
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A vă dl 0 Aa ANAL EENEN 


/* semaforul s7 se creează cu contorul inițializat la 1 */ 
/* semaforul s2 se creează cu contorul inițializat la 0 */ 
/* semaforu] s3 se creează cu contorul inițializat la z */ 


ee FER e eee e RR RER EREI ERA RR RR 


i/* PROCEDURA CONSUMATORILOR */ 
Í PR RR RR He He ke e de RE He e RR de He Ae ke RER RR RR et / 


1. execută _s wait(s2,0); 
/* aşteaptă la semaforul s2 până când acesta */ 
/* garantează că zona tampon nu este vidă */ 
2. execută _s wait(s1,0); 
/* aşteaptă la semaforul s7 până când acesta */ 
/* garantează că nici un task nu execută o* 
/* secțiune critică de accesare a zonei tampon */ 
3. extrage o dată din zona tampon; 
4. execută _s signal (s3); 
/* semnalează că din zona tampon */ 
/*a fost extrasă o (nouă) dată */ 
5. execută _s signal(s1); 
/* semnalează că taskul curent şi-a încheiat */ 
/* secțiunea critică de accesare a zonei tampon */ 


ig. 7.3.1_3 . Modelul producătorilor şi al consumatorilor 
-procedura consumatorilor. 


ÎNTREBĂRI: 


1). În ce consistă mecanismul semafoarelor? | 
2). Care sunt. cele mai: comune. ` probleme del 
sincronizare rezolvate cu mecanisinul 
semafoarelor?: j | 

3). Cüm se Jace sincronizarea. prin semafoare: a unuit 
număr de taskuri cu un eveniment concret e? | 

4). Prezentaţi. procedura producătorilor din modelul) 

` producătorilor şi consumatorilor. : Î 
3). Prezentaţi procedura. consumatorilor din modelul 
_ producătorilor şi consumatorilor. | 
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7.3.2. Sincronizarea prin blocuri 
eveniment 


Mecanismul de sincronizare prin blocuri eveniment este 
asemănător cu mecanismul de excludere mutuală prin fanioane 
active. 


Din punct de vedere conceptual, un bloc eveniment este un 
ansamblu format dintr-o variabilă booleană B şi o coadă C. 


Valoarea "1" a variabilei semnifică faptul că un eveniment 
căruia ea i se asociază s-a produs, iar valoarea "0" -că 
evenimentul nu s-a produs. Evident, la crearea blocului 
eveniment, se asigură pentru variabilă valoarea "0", iar coada 
se videază. 


Când un task ajunge în stadiul în care necesită sincronizarea 
cu un eveniment, se autoblochează și se înscrie în coada de 
aşteptare a blocului eveniment asociat evenimentului respectiv. 
Când evenimentul se produce, toate taskurile înscrise în coada 
de aşteptare la el sunt deblocate deodată. Transpare din aceste 
precizări faptul că mecanismul de sincronizare prin blocuri 
eveniment nu asigură memorarea evenimentelor. De aceea, 
variabila B nici nu trebuie să existe de facto; prezența ei în 
definiția blocului eveniment este bazată exclusiv pe 
considerente conceptuale. 


Sincronizarea prin blocuri eveniment este eficientă şi se 
recomandă a fi preferată în situațiile în care se impune ca mai 
multe  taskuri să-și sincronizeze rularea cu un anumit 
eveniment, fără a se cere memorarea acestuia. 


Implementarea mecanismului de sincronizare prin blocuri 
eveniment presupune înainte de toate adoptarea unei accepțiuni 
concrete asupra noțiunii de bloc eveniment. Vom considera 


blocul eveniment drept structură formată din: 
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- un tablou de tipul uschar, cu MAX TSK clemente, 
dedicat a servi drept coadă a blocului eveniment; fie 
coada[] numele acestui tablou; 

- o variabilă de tipul pointer către un caracter fără semn, 
având rolul de a asista intrarea în şi ieșirea din coada 
blocului eveniment; fie pie numele acestei variabile. 


Dacă adoptăm numele EVENT pentru această structură, 
atunci ca va putea fi introdusă printr-o declarație de forma: 


typedef struct 
uschar coada [MAX TSK] ; 
uschar *pie; 

JEVENT; 


Fig. 7.3.2_1. Declararea tipului de dată EVENT. 


Toate blocurile eveniment de care dispune un sistem se 
grupează sub forma unui tablou. Dacă admitem că numărul 
maxim de blocuri eveniment este MAX_EVN, atunci acest 
tablou -fie _evn{] numele lui-, va fi declarat astfel: 


i 


EVENT _evn[MAX_EVN] ; 


Fig. 7.3.2_2. Declararea tabloului de blocuri eveniment _evr/7. 


Este de subînțeles că declarația de mai sus trebuie să apară în 
afara oricăror acolade, fiind necesar ca tabloul _evn// să aibă 
statut de variabilă globală, deci: să fie cu locare statică în 
memorie. 


Un bloc eveniment concret, va fi exploatat cu ajutorul 
indicelui său în cadrul tabloului de blocuri eveniment, 
introducând câte un identificator pentru fiecare indice. 


Funcţiile prin care utilizatorul poate face referiri la un bloc 
eveniment sunt reunite în figura 7.3.2_3. 
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void _e init(void) 
/* inițializează tabloul de blocuri eveniment, */ 


/* prin atribuirea valorii NULL componentelor pie */ 


/* ale tuturor elementelor sale */ 


void _e_creat (uschar *evnidadi) 
/* alocă un element al tabloului _evn/7 */ 
i furnizează indicele respectivului element */ 
/* prin variabila pointată de evnidadr */ 


void _e_destroy(uschar evnid) 
/* dezalocă elementul tabloului _evn/7 */ 
/* cu indicele evnid, repunându-l la */ 
/* dispoziţia funcţiei _e_creat() */ 


void _e_wait(uschar evnid, usint timeout) 
/* blochează taskul curent şi înscrie-l */ 
/* în coada blocului eveniment cu indicele evnid;, */ 


/* cât taskul curent poate rămâne blocat */ 
/* la blocul eveniment */ 


void _e_signal (uschar evnid) 
/* deblochează toate taskurile aflate în */ 
/* coada blocului eveniment cu indicele evnid */ 


/* reține valoarea argumentului timeout ca timp limită * 


Fig. 7.3.2_3. Funcţiile de exploatare a blocurilor eveniment. 


Funcţia _e_init() 


Această funcție are rolul de a iniţializa tabloul de blocuri 
eveniment, prin stabilirea valorii NULL pentru componentele 


pie ale tuturor elementelor sale. 


Textul C al funcției _e_inizQ) este redat în figura 7.3.2 4. 
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void _e init{(void){ 
EVENT *e; 
uschar j; 
uschar i; 


_lock(); 

e=&_evn[0]; 

for (j=0;3<MAX_EVN; j++) { 
e->pie=NULL; 


for (i=0;i<MAX_TSK;i++){ 
e->coada [i] =MAX_TSK; 

) 

ett; 


} 
_unlock () ; 


Fig. 7.3.2_4. Textul funcției _e_ini/(). 


Funcţia _e_create() 


Funcţia _e_create() are rolul de a identifica un element liber 
al tabloului de blocuri eveniment _evn// şi de a-l aloca, 
furnizând indicele-i. De asemenea, funcției _e_creare() îi 
revine sarcina de a poziţiona pointerul pie al blocului 
eveniment pe care îl alocă, pe primul element al cozii. 


Textul C al funcţiei _e_create() este redat în figura 7.3.2_5. 


void _e create (uschar *evnidadr) { 
EVENT te; 
uschar 3; 
_ lock 0: 
e=&_evn[0]; 


j=0; 

while ( (e->pie)&&(j<MAX_EVN) ){ 
ett; 
E E 


OONO BPWNBE 


Fig. 7.3.2_5. Textul funcţiei _e_create() -partea întâi. 
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if (j<MAX_EVN) | 
e->pie=& (e->coada [0]) ; 


} 


else{ 


abort ("Eroare in taskul %2d: Tentativa: 


de a crea mai mult de MAX EVN (%2d) 
blocuri-eveniment", _tsk crt, 
MAX_EVN) ; 

) 

tevnidadr=j ; 

_unlock () ; 


Fig. 7.3.2_5. Textul funcției _e_create() -partea a doua. 


Funcţia _e_destroy() 


Funcţia _e_destroy() are rolul de a dezaloca elementul 
tabloului de blocuri eveniment _evn// cu indicele specificat 
prin valoarea argumentului ei, atribuind valoarea NULL 
componentei pie a acestui clement. În acest fel, elementul în 
cauză este lăsat la dispoziția funcţiei _e_create(), în vederea 
unei noi alocări. 


Se precizează că este interzisă distrugerea unui bloc 
eveniment a cărui coadă este nevidă. De aceea, funcția 
_e_destroy() va ctectua o verificare a cozii blocului eveniment 
vizat a fi distrus şi va proceda la distrugere doar dacă coada 
este vidă. Altfel, acţiunea funcţiei se va rezuma doar la 
generarea unui mesaj de eroare. 


Textul C al funcţiei _e destroy face obiectul figurii 
7.3.2 6. 
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void _e destroy (EVN_IDENT evnid) { 

EVENT *e; 

_lock () ; 

e=t&_evnievnid] ; 

if (e->pie!=& (e->coada[0])) 4 

abort ("Eroare in taskul %2d: Tentativa 

de a distruge un bloc-eveniment 
(%2d) cu coada nevida!", _tsk_cert, 
evnid) ; 


1 
2 
3 
4 
5 
6 
7 
8 


) 

elsej 
e->pie>=NULL ; 

) 


_unlock () ; 


Fig. 7.3.2_6. Textul funcției _e_destroy(). 


Funcţia _e_wait() 


Funcţia _e_wair() are rolul de a bloca taskul care o execută 
şi de a-l înscrie în coada blocului eveniment cu indicele 
specificat prin argumentul evnid. Operația de blocare a 
taskului în cauză se asigură prin apelul funcției _s/eep(). 
Întrucât, aşa cum s-a menţionat deja, prin funcţia _e_wair() se 
fixează şi un timp limită în care taskul curent poate rămâne 
blocat la blocul eveniment, este de subînțeles că cel de-al 
doilea argument al ei va fi transmis funcției _s/eep(). 
Neproducerea evenimentului în intervalul stabilit prin acest 
argument va conduce la deblocarea automată a taskului în 
cauză. O asemenea deblocare reprezintă o anomalie care 
trebuie tratată în mod corespunzător de către utilizator. 
Evident: tratarea anomaliei presupune mai întâi detectarea ei, 
detectare realizabilă cu ajutorul funcției _7ochk(). 


Rezultă, aşadar, pentru funcția _e_wai/(), textul C din 
figura 7.3.2_7. 
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void _e wait (uschar evnid, usint timeout) | 
EVENT fe; 
_lock () ; 
e=&_evnlevnid] ; 
*e->pie=_tsk_crt; 
(e->pie) ++; 
_sleep (timeout) ; 
_unlock () ; 


1 
2 
3 
4 
5 
6 
7 
8 
9 


~ 


Fig. 7.3.2_7. Textul funcției _e_wair(). 


Funcţia _e_signal() 


Funcția _e_signal() are rolul de a debloca toate taskurile 
aflate în coada blocului eveniment cu indicele specificat prin 
argumentul său evnid. Deblocarea taskurilor se asigură prin 
apelul funcţiei _wakeup(). Dacă nici un task nu așteaptă 
evenimentul în cauză, funcția _e_sienal() nu are nici un efect. 


Textul C al funcţiei _e_signal() este redat în figura 7.3.2_8. 


i 1 void _e_ signal (uschar evnid) ( i 
| 2 EVEN «e; i 
3 uschar k; i 
4 _lock(); 
t] e=&_evn[evnid] ; 
6 while (e->pie!=& (e->coada [0])) ( 
7 (e->pie) --; 
8 k=* (e->pie) ; 
9 * (e->pie)=MAX_TSK; 
10 _wakeup (k) ; 
11 ) 


12 _unlock () ; 


Fig. 7.3.2_8. Textul funcției _e_signal (). 
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Se poate înțelege, din cele de mai sus, că taskurile care 
utilizează pentru sincronizare mecanismul blocurilor eveniment 
trebuie să execute, când ajung în punctul în care se impune 
sincronizarea, funcția e _wair(), cu referire la blocul eveniment 
asociat evenimentului în cauză. Semnalarea evenimentului se 
va asigura prin funcţia _e_signal(), cu referire la acelaşi bloc 
eveniment. Funcţia _e_sienal() poate fi prevăzută fie într-un 
alt task, fie într-o rutină de tratare de întrerupere, după cum 
evenimentul este abstract, respectiv concret. Figura 7.3.2 9 
ilustrează concret cele de mai sus, pentru cazul sincronizării a 
două taskuri, A şi B, cu un eveniment e, de tip concret. 


TASK_AQ) 
£ 


întrerupere 


(e) 


ewal e,0); 


ETT, 

} 4— |æ RUTINĂ DESERVIRE */ 
/* ÎNTRERUPERE  */ 
pp e ee este te te stele 
_e_signal(e); 

TASK_B0 ~ 

£ 

_e_wait(e,0); 


Fig. 7.3.2_9. Sincronizarea taskurilor A şi B cu evenimentul 
legat de întreruperea e. 
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ÎNTREBĂRI: 


.. Definifi notiunea de bloc eveniment. 
Ce este, în plan practic, un bloc eveniment? 
În ce consistă mecanismul blocurilor eveniment? 
; Precizaţi rolul funcției: e. init). ; 
„` Descrieji actiunile functiei- e- init). 
5), Daţi o implementare C pentru functia _e_init): 

-Precizaţi rolul funcţiei .e_create(). 
 Descrieți acțiunile functiei e createQ). 
"Daţi o implementare C pentru funcţia e createQ). 
... Precizaţi rolul funcţiei. destroyQ. 
 Descrieţi acțiunile funcţiei e. destroy(). 
Daţi o implementare C pentru functia ..e:.destroy): 
Precizati rolul funcţiei. e. wait). 
| Descrieți acțiunile funcției e waitQ. 
i lementare C pentru functia e: wait). 
lul functiei: e. signalQ). 
: Descrieţi acțiunile funcției. e. sional(). 

8). Daţio implementare C pentru funcția _e_signalQ). 
îi Cum se asigură. sincronizarea. prin: mecanismul, 
"iu blocurilor eveniment a unui. mumă de taskuri cuun 

eveniment concret e? 
20)... Ce avantaje . prezintă mecanismul: blocurilor 

eveniment? 


21): Ce dezavantaje prezintă mecanismul blocurilor 
eveniment? A 


7:3:3: Sincronizarea prin blocuri 
multieveniment 


Din punct de vedere conceptual, un bloc multievenimment 
este un ansamblu format dintr-o mulţime de variabile booleene, 
o funcţie logică definită pe această mulțime. sau pe o 
submulțime a ei şi o coadă. Fiecare variabilă booleană 
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corespunde unui eveniment. Mulțimea variabilelor booleene 
reprezintă, prin urmare, o mulțime de evenimente. Implicit, 
funcţia logică va fi o funcţie de evenimente. 


Valoarea logică "1" a unei variabile semnifică faptul că 
evenimentul asociat ei s-a produs, iar valoarea "0" -contrariul. 


Funcţia logică din cadrul unui bloc multieveniment poate fi 
fie ŞI, fie SAU. 


Sincronizarea prin blocuri multieveniment constă în 
aşteptarea, respectiv semnalarea, valorii logice "1" a unei 
funcţii de evenimente sau, cu alte cuvinte, în aşteptarea, 
respectiv semnalarea, unei anumite configurații a stadiilor în 
care se află un număr de evenimente. 


Taskurile interesate de o asemenea configurație de 
evenimente trebuie, mai întâi, să o specifice, iar apoi să se 
autoblocheze şi să se înscrie, în aşteptarea ei, în coada blocului 
multieveniment în cauză. 


Semnalarea apariției unei configurații de evenimente 
așteptată este însoțită de deblocarea tuturor taskurilor aflate în 
coada corespunzătoare ei. 


Înainte de a aborda problema implementării mecanismului 
de sincronizare prin blocuri multieveniment, se impun câteva 
precizări de ordin concret. 


Mulțimea evenimentelor se poate reprezenta sub forma unei 
variabile de un tip întreg fără semn, instituind, convenţia că 
fiecare bit al ei corespunde unui eveniment. 


Submulțimea pe care este definită funcția logică poate fi 
precizată cu ajutorul unei măşti. Aceasta va fi tot o variabilă de 
un tip întreg fără semn, acelaşi care se adoptă şi pentru 
mulțimea evenimentelor, având biţi de valoare "1" în toate 
poziţiile corespunzătoare unor evenimente care aparțin 
submulțimii şi biţi de valoare "0" în celelalte poziţii. Evident, 
când funcția este definită pe întreaga mulțime a evenimentelor, 
toţi biții măştii vor avea valoarea "1". 
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Specificarea unei configurații de evenimente care reprezintă 
o condiţie. de sincronizare se face indicând masca potrivită, 
tipul funcţiei logice şi valorile pe care trebuie să le aibă biții 
corespunzători evenimentelor respective, pentru ca această 
functie să ia valoarea "1". Denumim aceste valori valori active. 


În conformitate cu "tradiția", o funcție logică de tip ȘI va lua 
valoarea "1" doar atunci când toate valorile indicate vor fi 
atinse deodată, iar o funcție logică de tip SAU -doar atunci 
când cel puțin una dintre aceste valori va fi atinsă. În alți 
termeni, însă, având în vedere una dintre teoremele lui de 
Morgan, se poate afirma că o funcție logică de tip SAU ia 
valoarea "1" doar atunci când nu toate negatele valorilor 
indicate vor fi atinse deodată. 


Se defineşte drept configurație de referință pentru funcția ŞI 
o mulțime de acelaşi cardinal cu mulțimea evenimentelor, 
obținută prin aplicarea măștii asupra submulțimii pe care este 
definită funcția logică (aplicarea măștii constă în efectuarea 
unei funcții logice ŞI între mască şi submulțimea completată cu 
elemente de valori oarecari, până la atingerea cardinalului în 
cauză). 


Se defineşte drept configuraţie de referință pentru funcția 
SAU o mulțime de același cardinal cu mulțimea evenimentelor, 
obținută prin aplicarea măștii asupra submulțimii pe care este 
definită funcția logică, după negarea valorilor elementelor 
acestei mulțimi. 


O configurație oarecare de evenimente va reprezenta o 
condiție de sincronizare definită printr-o funcție ŞI dacă, 
aplicându-i masca, se obține o valoare identică cu cea a 
configurației de referință corespunzătoare respectivei condiții 
de sincronizare. 


O configurație oarecare de evenimente va reprezenta o 
condiție de sincronizare definită printr-o funcție SAU dacă, 
aplicându-i. masca, se obține o valoare diferită de cea a 
configurației de referință corespunzătoare respectivei condiții 
de sincronizare. 
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Pentru ilustrarea celor de mai sus, se consideră, în 
continuare, două exemple, presupunând că mulțimea 
evenimentelor este de cardinal 8 şi că evenimentele poartă 
indici egali cu rangul biţilor prin care se reprezintă. 


Exemplul 1 


Se consideră drept condiţie de sincronizare atingerea 
deodată a valorilor 1, 0, 1, 1 de către evenimentele 0, 2, 3 şi 6, 
respectiv. 


Această condiţie de sincronizare se va specifica astfel: 
masca: 01001101 
funcţia logică: ŞI 


valorile active: *1**10*1 


Notă: 
Cu "*" s-au marcat biții ale căror valori sunt indiferente. 


Configurația de referință corespunzătoare condiției de 
sincronizare considerată se obține astfel: 


configuraţia de referință = 01001101 & *1**10%1 = 01001001 
Configuraţiile oarecari: 
00001001 (00001001 & 01001101 = 00001001 != 01001001) 


01001101 (01001101 & 01001101 = 01001101 != 01001001) 
etc. 


nu reprezintă condiția de sincronizare. 
Configuraţiile oarecari: 
01001001 (01001001 & 01001101 = 01001001 == 01001001) 
11001001 (11001001 & 01001101 = 01001001 == 01001001) 
11111001 (11111001 & 01001101 = 01001001 == 01001001) 


etc. 


reprezintă condiţia de sincronizare. 
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Exemplul 2 


Se consideră drept condiţie de sincronizare atingerea la un 
moment a cel puţin uneia dintre valorile 1, 0, 1, 1 de către 
evenimentele 0, 2, 3 şi 6, respectiv. 


Această condiţie de sincronizare se va specifica astfel: 
masca: 01001101 
functia logică: SAU 
valorile active: *1%**10%1 


Configuraţia de referință corespunzătoare condiției de 
sincronizare considerate se obține astfel: 


configuraţia de referință=01001101 & (~"1**10*1) = 00000100 
Configuraţiile oarecari: 


00100110 (00100110 & 01001101 = 00000100 == 00000100) 
10110110 (10110110 & 01001101 = 00000100 == 00000100) 


etc. 
nu reprezintă condiţia de sincronizare. 
Configuraţiile oarecari: 


01000100 (01000100 & 01001101 = 01000100 != 00000100) 
11001001 (11001001 & 01001101 = 00001100 != 00000100) 


etc. 
reprezintă condiția de sincronizare. 


Pentru implementarea mecanismului de sincronizare prin 
blocuri multieveniment, se defineşte, mai întâi, tipul de dată 
FOR_ME (FOR_ME provine de la FOR MultiEvent) ca o 
structură cuprinzând: 

- o variabilă de tipul usshorț, care reprezintă, prin biții 
săi, mulțimea evenimentelor şi în care se înregistrează 
configuraţiile de referință; fie evntval numele acestei 
variabile 
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- o variabilă de tipul usshort, reprezentând o mască prin 
care se desemnează  submulțimea evenimentelor 
vizate de funcția logică; fie mask numele acestei 
variabile. Se precizează că această variabilă are şi rolul 
de a indica, prin valoarea sa nulă, respectiv nenulă, 
absența, respectiv prezența cel puțin a unui task în 
coada blocului multieveniment 

- o variabilă de tipul usshorţ, dedicată codificării 
operației efectuate de funcția logică asupra 
evenimentelor; fie oper numele acestei variabile. 


Tipul de dată FOR_ME se va introduce, deci, printr-o 
declaraţie de forma: 


typedef struct 
usshort evntval; 
usshort mask; 
usshort oper; 
)FOR_ME; 


Fig, 7.3.3_1. Declararea tipului de dată FOR_ME. 


Un bloc multieveniment va trebui să cuprindă câte o 
structură FOR_ME pentru fiecare task. Este firesc, atunci, ca 
toate structurile FOR_ME din cadrul aceluiaşi bloc 
multieveniment să fie grupate sub forma unui tablou. Fie 
for_mel] numele acestui tablou. 


Alături de un tablou for_me//, în compoziția unui bloc 
multieveniment trebuie introdusă şi o variabilă de tipul zschar, 
care să servească drept indicator de alocare a blocului. Se va 
adopta convenţia ca valoarea nulă a acestei variabile să 
corespundă situației când blocul nu este alocat, iar o valoare 
nenulă -situației când blocul este alocat. Fie nfree numele 
acestei variabile. 
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Se poate conchide, acum, că un bloc multieveniment va fi o 
structură formată din tabloul for_me/] şi variabila nfree. 


Întroducem, corespunzător acestei structuri, tipul de dată 
MULTIEVENT. Declararea lui se va face astfel: 


typedef struct 
FOR_ME for_me [MAX _TSK] ; 


uschar nfree; 
IMULTIEVENIT ; 


Fig. 7.3.3_2. Declararea tipului de dată MULTIEVENT. 


Cum într-un sistem există mai multe blocuri 
multieveniment -presupunem MAX_ME numărul acestora-, 
vom proceda la gruparea lor într-un tablou.  Admiţând 
pentru acest tablou numele _me//, el va fi introdus prin 
următoarea declaraţie: 


| MULTIEVENT _me [MAX ME] ; 


Fig. 7.3.3_3. Declararea tabloului de blocuri multieveniment _me//. 


Pentru mai multă claritate, se oferă în figura 7.3.3 4 o 
reprezentare sinoptică a structurilor de date introduse. 


Mecanismul de sincronizare prin blocuri multieveniment se 
utilizează cu ajutorul funcțiilor sintetizate în figura 7.3.3_5. 
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evntval evntval 
mask mask nfrec 
oper oper 
for_me[0] for_me[MAX_TSK-1] 
for_me[] nfree 
_me[0] 


evntval evntval 
mask mask nfree 
oper oper 


for_me[0] for_me[MAX_TSK-1] 


tor_me[] nfree 


_me[MAX_ME-1] 


mef] 


Fig. 7.3.3_4. Reprezentare sinoptică a structurii de date 
a mecanismului de sincronizare prin blocuri multieveniment. 
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void _me_init(void) 
/* iniţializează tabloul de blocuri multieveniment, */ 
/* prin atribuirea valorii zero */ 
/* componentelor pie ale elementelor sale */ 


void _ me_create(uschar *meidadr) 

/* alocă un element al tabloului _me/] */ 
/* şi furnizează indicele respectivului element */ 
/ prin variabila pointată de meidadr */ 


void _me_destroy(uschar meid) 
/* dezalocă elementul tabloului _me{] */ 
/* cu indicele meid, repunându-l la */ 
/* dispoziția funcției _me_create() */ 


void _ me_wait (uschar meid, usshort evy, 
usshort msk, usshort op, usint timeout) 
/* blochează taskul curent şi înscrie-l */ 
/* în coada blocului multieveniment cu */ 
/* indicele meid, reţinând în structura */ 
/* for_me a acestui bloc, corespunzătoare */ 
/* taskului în cauză, argumentul msk; */ 
/* reţine, de asemenea în această structură, */ 
/* argumentele evv şi op şi înregistrează */ 
/* valoarea argumentului timeout ca timp */ 
/* limită câttaskul curent poate rămâne */ 
/* blocat la blocul multieveniment; */ 


i 
i 


void _me_signal (uschar meid, usshort evy) 
/* deblochează toate taskurile aflate în */ 
/* coada blocului multieveniment cu indicele meid, * 
/* satisfăcute de configu raţia de evenimente */ 
/* precizată prin argumentul evy */ 


Fig. 7.3.3_5. Funcţiile de exploatare a blocurilor multieveniment 
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Funcția _me_init() 


Această funcţie are rolul de a iniţializa tabloul de blocuri 
multieveniment, prin stabilirea valorii zero pentru 
componentele nfree ale tuturor elementelor sale. 


Textul C al funcției _me_init() este următorul: 


1 void _me_init (void) { 

2 MULTIEVENT *m; 

3 uschar j; 

4 uschar i; 

5  _lock(); 

6 m=& me[0]; 

7  for(j=0;j<MAX_ME;j++){ | 

8 m->nfree=0 ; | 

9 for (i=0;i<MAX_TSK; i++) { | 
10 m->for_me[i] .mask=0; | 
11 ) i 
12 mit; 
13) i 

| 


14 _unlock () ; 


Fig. 7.3.3_6. Textul funcției _me_init(). 


Funcţia _me_create() 


Funcţia _me_create() are rolul de a identifica un element 
liber al tabloului de blocuri multieveniment _me// şi de a-l 
aloca, furnizând indicele-i. De asemenea, funcției me _create() 
îi revine sarcina de a forța valoarea zero pentru toate 
componentele mask ale blocului multieveniment pe care îl 
alocă, vidând, astfel, coada acestui bloc. 


Se reamintește că o valoare nenulă a unei componente mask, 
dincolo de aceea că desemnează submulțimea de evenimente 
pe care este definită funcţia logică de care este interesat taskul 
pus în corespondență cu acea componentă, semnifică şi faptul 
că taskul respectiv se află-în coada blocului multieveniment în 
cauză. 
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Textul C al funcţiei me create() este redat în figura 
TIB T 


1 void me_create (uschar *meidadr) { 

2 MULTIEVENT *m; 

3 uschar 3; 

4 uschar i; 

5 _lock () ; 

6 m=&_me [0] ; 

7 j=0; 

8 while ({(m->nfree) &&(j<MAX_ME) ) { 

9 mt; 
10 fe ak 

11) 

12 i£(3<MAX ME) ( 
13 m->nfree=L; i 
14 for (i=0;i<MAX_TSK; i++) { | 
15 m->for_me[i] .mask=0; N 
16 ) i 
17 } i 
18 else [ | 
19 abort ("Eroare in taskul %2a: Tentativa 
20 de a crea mai mult de MAX ME (524) | 
21 blocuri-multieveniment", _tsk_crt, 

22 MAX_ME) ; i 
23 } i 


24 *meidadr=j ; 
25 _unloek () ; 
26 ) 


Fig, 7.3.3_7. Textul funcţiei _me_create(). 


Funcţia _me_destroy() 


Funcţia _me_destroy() are rolul de a dezaloca elementul 
tabloului de blocuri multieveniment cu indicele specificat prin 
valoarea argumentului ei, atribuind valoarea zero componentei 
nfree a acestui element. În acest fel, elementul în cauză este 
lăsat la dispoziţia funcţiei _me_create(), în vederea unei noi 
alocări. 
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Se precizează că este interzisă distrugerea unui bloc 
multieveniment a cărui coadă este nevidă. De aceea, funcția 
_me_destroyQ) va efectua o verificare a cozii blocului 
multieveniment vizat a fi distrus şi va proceda la distrugere 
doar dacă coada este vidă. Altfel, acțiunea funcției se va 
rezuma la generarea unui mesaj de eroare. 


Textul C al funcţiei _me_ destroy() este redat în figura 
7.3.3_8. ` 


void _me destroy (uschar meid) { 
MULTIEVENT *me; 


T 

2 

3 uschar j; 
4 _lock{}); 
5 

6 

7 

8 


me=&_me [meid] ; 

3=0; 

while ( (me->for_me [5] .mask==0) 
&& (3<MAX_TSK) ) | 


| 

| 

H 
9 j++; | 
10 ) i 
11 if (J<MAX_TSK) { f 
12 abort ("Eroare in taskul %2d: Tentativa | 
13 de a distruge un bloc-multieveniment | 
14 (%2d) cu coada nevida!", _tsk_crt, 
15 meid) ; | 
16 ) i 
17 elseţ i 
18 me->nfree=0; i 
19 ) i 


20 _unlock () ; 


Fig. 7.3.3_8. Textul funcției _me_destroy(). 


Funcţia me wait) 


Funcția me _wait() are rolul de a bloca taskul care o execută 
şi de a-l înscrie în coada blocului multieveniment cu indicele 
meid, reţinând în structura for me a acestui bloc, 
corespunzătoare taskului în cauză, argumentul msk. 
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De asemenea, funcţia _me_wair() reţine, în aceeaşi structură, 
argumentul op, apoi determină configurația de referință 
corespunzătoare condiţiei de sincronizare specificată prin 
argumentele msk, op şi ev şi o înscrie în componenta evnival 
a respectivei structuri. 


Operația de blocare a taskului se asigură prin apelul funcției 
_sleep(), căreia i se transmite argumentul fimeour, în 
vederea limitării timpului cât taskul poate rămâne blocat la 
blocul multieveniment. Neproducerea  multievenimentului în 
intervalul stabilit prin acest argument va conduce la deblocarea 
automată a taskului în cauză. O asemenea deblocare reprezintă 
o anomalie care trebuie tratată în mod corespunzător de către 
utilizator. Evident: tratarea anomaliei presupune mai întâi 
detectarea ei, detectare realizabilă cu ajutorul funcției _/ochk(). 


Pentru facilitarea determinării configurației de referință, se 
va codifica operatorul logic ŞI prin valoarea hexazecimală 
0x0000, iar operatorul logic SAU prin valoarea hexazecimală 
OxFFFE, ambele de tipul: usshort. Argumentul op va avea, 
deci, la un moment, una dintre aceste două valori. Rezultă că, 
aplicând operatorul SAU EXCLUSIV (^) între valoarea acestui 
argument şi valoarea argumentului ewy, se obține, ca rezultat, 
complementul valorii evv, în cazul operației SAU, respectiv 
chiar această valoare, în cazul operaţiei ŞI. 


Pentru a nu se pretinde utilizatorului cunoaşterea acestei 
codificări, se vor pune la dispoziţia lui simbolii AND, respectiv 
OR, definiţi cu ajutorul preprocesorului, după cum urmează: 


4 define AND 0x0000 


# define OR OxEFFF 


Fig. 7.3.3_9. Definirea simbolilor AND şi OR. 


Textul C al funcției _me_wait() este redat în figura 7.3.3_10. 
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1 void _me_wait(uschar meid,: usshort evv, 

2 usshort msk, usshort op, usint timeout) { 
3 FOR_ME *fm; 

4 _lock () ; 

5 fm=&_me[meid] .for_me[_tsk_ crt]; 

6 

7 

8 

9 

0 


fm->evntval=msk& (evv^op) ; 
fm->mask=msk; 
fm->oper=op; 

_sleep (timeout) ; 

_unlock () ; 


Fig, 7.3.3_10. Textul funcţiei _me_wair(). 


Funcţia _me signal) 


Această funcţie are rolul de a debloca toate taskurile aflate în 
coada blocului multieveniment cu indicele meid, pentru care 
configuraţia de evenimente precizată prin argumentul evv 
reprezintă condiția de sincronizare așteptată. 


Deblocarea  taskurilor se asigură prin apelul funcţiei 
_wakeup(). Cu ocazia deblocării, taskurile sunt radiate din 
coada blocului multieveniment în cauză, prin înscrierea valorii 
zero în componenta mask a structurii for_me corespunzătoare 
lor. 


Dacă nici un task nu este satisfăcut de configurația de 
evenimente precizată prin evv, funcția _me_signal() rămâne 


fără nici un efect. 


Textul C al funcției _me signal() este redat în figura 
Ta-aa 11; 
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void _me_ signal (uschar meid, usshort evv) (continuare) 
FOR ME *fm; bens 
Ñ ÎNTREB. — 


1 

2 

3 uschar k; 

4 uschar aux; 
5 _lock(); 
6 

7? 

8 

9 


9). Precizăţi rolul funcției. me. int). 
10). Descrieţi acțiunile funcţiei. me. ini)... | 
"1, Daţi o implementare C pentru funcția me. înit). i 
12). Precizaţi rolul funcției me. create(). ; 
1 3). Descrieţi acțiunile functiei me_create(). 
i 14). Daţi "o “implementare e pentru. * funeral] 
i _me create). $ | 
i 15). Precizaţi rolul funcției. me destroy). 
pă 16). Descrieti acțiunile funcției me destroy(). ; i 
i 17). Däi o implementare C pom funcția 
; _me_destroy(). t sai 


fm=&_me [meid] .for_me[0]; 
for (k=0;k<MAX_TSK;k++) | 
i£ (Em->mask) { 
aux= (Fm->evntval== ( (fm->mask) &evv) ) ; 

10 i£ (((! (fm->oper) ) &s (aux) ) 
d | | ((Em->opez) && (!aux))) | 
12 £fm->mask=0 ; 
13 _wakeup (k) ; 


15 ) 
16 Em++; 


SG e 9 


_unlock () ; f ; 
! i 16). Peta rolul fimcţiei me E wait). 
! i 19). 
i i 20). 


21). Precizaţi rolul: functiei. 
22). Descrieti acțiunile funcției me signal... 
23). Daţi o “implementare C pom futa) 
me sional(). a | 
24). Ce. avantaje... prezintă mecanismul. blocurilor 
- mulțieveniment?, | 
25). Ce. dezavantaje. prezintă. mecanismul blocurilor 
multieveniment? 


cD: Defniţi noțiunea de bloc. nulieveniment 

o 2). Cese înțelege prin valori active? ; 

3). Ce se înțelege prin confi gurapie de refer ina pentru 

=- funeția ŞI? : 

4). Ce se înțelege prin configurație de referință pentru 
Jungia SAU? 

5). Cese înțelege pr in. condiție de sincr onizare defi înită 

printr-o funcție SI? A : 

6). Ce se înțelese prin condiție de sincronizare defi nită, 

printr-o funcție SAU? ; 


7.3.4. Sincronizarea prin blocuri 
rendez-vous 


În unele situații, este necesar să se asigure ca un număr de 
taskuri să ajungă toate în anumite stadii ale rulării lor, 
indiferent în ce ordine şi abia după aceea să poată din nou 
avansa. 


7). Ce este, în plan practic, un bloc multieveniment? 
"8. În ce. consistă mecanismul blocurilor 
mulieveniment? : o 


E E 


(se continuă) 
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Se poate considera, deci, că în aceste situații, există un punct 
în spațiul multidimensional al acțiunilor respectivelor taskuri în 
care ele au stabilită o întâlnire, după care, din nou, drumurile 
lor se despart. Figura 7.3.4_1 oferă o reprezentare a unei 
asemenea situaţii, care, evident, ridică o problemă de 
sincronizare diferită de cele avute în vedere până aici. 


TASKUL A TASKUL B TASKUL C 


Y 


TASKUL A TASKUL B TASKUL C 


Fig. 7.3.4_1. Exemplu de "rendez-vous" între trei taskuri. 


Problemele © de sincronizare de tipul relevat se rezolvă 
printr-un mecanism special, dezvoltat în jurul conceptului de 
bloc rendez-vous. 


Un bloc rendez-vous este, din punct de vedere principial, un 
ansamblu format dintr-o variabilă întreagă cu rol de contor şi o 
coadă de aşteptare. 
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Contorul indică, iniţial, numărul taskurilor care trebuie să se 
întâlnească, iar curent, numărul taskurilor care încă nu au ajuns 
la întâlnire. 


Coada servește înregistrării taskurilor care au ajuns deja la 
întâlnire, blocându-se, cu această ocazie, în aşteptarea 
celorlalte. 


De fiecare dată când un task ajunge la întâlnire, valoarea 
contorului se decrementează cu o unitate. Atingerea, prin 
decrementări succesive, a valorii zero semnifică faptul că 
întâlnirea a avut loc în formaţie completă și determină 
deblocarea tuturor taskurilor care au participat la ea. 
Deblocarea se efectuează pe baza conținutului cozii. 


Uzual, un bloc rendez-vous asigură şi posibilitatea fixării 
unui timp limită în care taskurile trebuie să sosească în punctul 
de întâlnire pentru ca aceasta să aibă loc. Dacă cel puţin un task 
nu reuşeşte să se încadreze în timpul fixat, întâlnirea se 
contramandează şi toate taskurile care au ajuns la ea sunt 
deblocate. 


Pentru ca taskurile vizate pentru o întâlnire să-și poată 
continua activitatea în cunoștință de cauză, în ceea ce priveşte 
reuşita sau cşecul respectivei întâlniri, se impune ca la 
deblocare să li se furnizeze o informaţie de stare referitoare la 
cele două alternative posibile. 


În vederea implementării mecanismului de sincronizare prin 
blocuri rendez-vous, se defineşte tipul de dată 
RENDEZ VOUS, ca o structură cuprinzând: 

- o variabilă de tipul uschar, reprezentând contorul 
blocului rendez-vous; fie contor numele acestei | 
variabile 

- un tablou de tipul uschar, cu MAX_TSK elemente, 
dedicat a servi drept coadă a blocului rendez-vous; fie 
coada[] numele acestui tablou i 

- o variabilă de tipul pointer către un caracter fără semn, 
având rolul de a asista intrarea în, respectiv ieșirea 
din coada blocului rendez-vous, fie pie numele 
acestei variabile 5 
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- o variabilă de tipul usint, dedicată memorării timpului 
limită în care toate taskurile vizate trebuie să sosească 
la întâlnire; fie timeout numele acestei variabile; 

- o variabilă de tipul uschar, destinată memorării 
modului în care a decurs întâlnirea; fie status numele 
acestei variabile. 


Rezultă, deci, că tipul de dată RENDEZ VOUS se va 
introduce printr-o declarație de forma: 


typedef struct{ 
uschar contor; 
uschar coada [MAX _TSK] ; 
uschar *pie; 
usint timeout; i 
uschar status; | 
)RENDEZ_VOUS; 


Fig. 7.3.4_2. Declararea tipului de dată RENDEZ_ VOUS. 


Toate blocurile rendez-vous de care se dispune în sistem se 
grupează sub forma unui tablou. Dacă admitem că numărul 
maxim de blocuri rendez-vous este MAX RV, atunci acest 
tablou -fie _rv// numele lui- va fi declarat astfel: 


RENDEZ_VOUS _rv[MAX_RV] ; 


Fig. 7.2.4_3. Declararea tabloului de blocuri rendez-vous. 


Este de subînțeles că declarația de mai sus trebuie să apară în 
afara oricăror acolade, fiind necesar ca tabloul _rv// să aibă 
statut de variabilă globală, deci: să fie cu locare statică în 


memorie. 


Evident, un bloc rendez-vous concret va fi exploatat cu 
ajutorul indicelui său, introducând câte un identificator pentru 


fiecare indice, 
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Funcțiile prin care utilizatorul poate face referiri la un bloc 
rendez-vous sunt: 


void _rv_init(void) 
/* inițializează tabloul de blocuri rendez-vous, */ 
/*prin atribuirea valorii zero */ 
/* componentelor contor ale tuturor elementelor sale */ 


void _rv_create(uschar *rvidadr, uschar ntv, usint timeout) 
/* alocă un element al tabloului _rv/7, */ 
/* şi furnizează indicele aferent respectivului element */ 
/* în variabila pointată de rvidadr; */ 
/* atribuie componentei contor a elementului */ 
/* alocat valoarea specificată prin */ 
/* argumentului n/v (numărul tashkurilor vizate); */ 
/* reține valoarea argumentului timeout */ 


void_rv_destoy(uschar rvid) 
/* dezalocă elementul tabloului _rv/7 */ 
/* cu indicele rvid, repunându-l la */ 
/* dispoziţia funcţiei _rv_create() */ 
/ iii A 
void _rv signal (uschar rvid) 
/* anunță sosirea la rendez-vous a taskului curent; */ 
/* dacă nu toate celelalte taskuri vizate */ 


/* sunt sosite, atunci taskul curent se blochează; */ 
/* altfel, are loc deblocarea tuturor */ 
/* taskurilor găsite blocate în aşteptarea întâlnirii */ 


Fig. 7.3.4_4. Funcţiile de exploatare a blocurilor rendez-vous. 
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Funcţia _rv_init) 


Această funcție are rolul de a iniţializa tabloul de blocuri 


rendez_vous, prin atribuirea valorii zero componentelor contor 


ale tuturor elementelor sale. 


Textul Cal funcției _rv_init() este următorul: 


1 void _rv_init (void) ( 

2 RENDEZ_VOUS *rv; 

3 uschar j; 

4 uschar i; i 
5 _lockţ); i 
6 rv=&_rv[0]; H 
7 for(j=0;j<MAX_RV;j++){ | 
8 rv->contor=0; i 
9 for (i=0;i<MAX_TSK; i++) { i 
10 rv->coada [i]=MAX_TSK; i 
11 ) 

12 rv++; 

13 ) 


14 _unlock () ; 


Fig. 7.3.4_5. Textul funcției _rv_init(). 


Funcţia _rv_create() 


Funcţia _rv_create() are rolul de a identifica un element 
liber al tabloului de blocuri rendez_vous, _rv/], și de a-l aloca, 
furnizând indicele-i prin variabila pointată de argumentul 
rvidadr. De asemenea, funcţiei _rv_create() îi revine sarcina de 
a poziţiona pointerul pie al blocului pe care îl alocă pe primul 
element al cozii, de a înregistra argumentele ntv şi timeout în 
componentele contor, respectiv timeout ale acestui bloc, şi de a 
forța la zero componenta status. 


Textul C al funcţiei _rv_create() este redat în figura 7.3.4_6. 
196 
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1 void _rv create(uschar *rvidadr, uschar îtv 
2 usint timeout) ( i 
3 RENDEZ_VOUS *rv; 

4 uschar j; 

5 _lock () ; 
6 

7 

8 


rv=&_rv[0]; 

Î=0; 

while ( (rv->contor) &£ (3<MAX_ RV) ) | 
9 Evtt; i 


24 _unlock(); 
25 *rvidadr=j; $ 


10 j++; 

11) 

12 if(j<MAX_RV){ 

13 rv->contor=ntv; } 

14 rv->pie=& (rv->coada [0]); % 

15 rv->timeout=timeout; X 

16 rv->status=0; A i 

173 | 

18 else{ | 

19 abort ("Eroare in taskul $2d: Tentativa | 

20 de a crea mai mult de MAX RV (%2d) i 

21 blocuri-rendez_vous", tsk crt, l 

22 MAX RV) ; sai | 

23 } l 
f 
i 
i 
i 
i 
i 
i 


Fig. 7.3.4_6. Textul funcției _rv creare. 


Funcţia _rv_destroy() 


Funcţia _rv_destroy() are rolul de a dezaloca elementul 
tabloului de blocuri rendez_vous cu indicele specificat prin 
valoarea argumentului ei, atribuind valoarea zero componentei 
contor a acestui element. În acest fel, elementul în cauză este 
lăsat la dispoziția funcției _rv create(), în vederea unei noi 
alocări. 
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Se precizează că este interzisă distrugerea unui bloc 
vendez vous a cărui coadă este nevidă. De aceea, funcția 
rv destroy() va efectua o verificare a cozii blocului 
rendez vous vizat a fi distrus şi va proceda la distrugere doar 
dacă coada este vidă. Altfel, acțiunea funcţiei se rezumă la 
generarea unui mesaj de eroare. 


Textul C al funcţiei _rv_destroy() este redat în figura 
7.3.4_7. 


1 void _rv destroy (uschar rvid) 4 

2 RENDEZ_VOUS *rv; 

3 _lock () ; 

4 rv=& _rv[rvid]; 

5 if (rv->pie!=&(rv->coada[0])){ i 
6 abort ("Eroare in taskul $2d: Tentativa | 
7 de a distruge un bloc-rendez_vous i 
8 ($2d) cu coada nevida!", _tsk crt, i 
9 rvid); i 
10 ) | 
11 else{ i 
12 rv->contor=0; i 
13 ) 


14 _unlock () ; 


Fig. 7.3.4_7. Textul funcției _rv_destroy(). 


Funcţia _rv_signai() 


Funcţia _rv_signal () are rolul de a anunța sosirea la rendez- 
vous a taskului în care ea se execută. 


În primul rând, funcția verifică, uzând de componenta 


contor a blocului rendez-vous, dacă nu cumva toate taskurile 
vizate pentru rendez-vous şi-au anunțat deja sosirea. 
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În caz afirmativ, se poziţionează la valoarea zero 
componenta sfatus a blocului rendez-vous, iar apoi are loc 
deblocarea de către taskul sosit ultimul a tuturor celorlalte 
taskuri implicate în întâlnire, pe baza conţinutului cozii. 
Deblocarea se efectuează prin apelul funcţiei _waheup(, 
repetat de câte ori este necesar. 


În caz negativ, taskul în care se execută funcția 
_rv signal) este blocat şi înscris în coada blocului 
rendez-vous cu indicele rvid. Operația de blocare se 
efectuează prin apelul funcţiei _sleep(), căreia i se transmite ca 
argument valoarea pe care o are componenta timeout a blocului 
rendez-vous în cauză. 


Deblocarea unui task înscris în coada unui bloc rendez-vous 
se poate produce în trei situații, ce pot fi deosebite prin valorile 
pe care le au componentele contor şi status ale blocului, 
imediat după deblocare. 


În prima dintre ele, caracterizată prin valoarea nulă atât a 
componentei contor, cât şi a componentei status, deblocarea 
este rezultatul ajungerii în timp util la întâlnire a ultimului task 
așteptat. În această situaţie, taskurile  oarecari dintre cele 
implicate în rendez-vous nu vor mai avea altceva de făcut, 
decât să înscrie în câmpul zo din contextul lor logic valoarea 
variabilei status, să-şi încheie secțiunea critică executând 
directiva _unlock() şi să părăsească funcţia _rv_sienal() 


În a doua situație, caracterizată prin valoarea nenulă a 
contorului, deblocarea este rezultatul expirării timpului afectat 
pentru realizarea întâlnirii înainte ca toate taskurile să ajungă în 
punctul prevăzut. În această situație, unul dintre taskurile care 
au fost blocate la blocul rendez-vous -în mod normal: primul- 
va fi reintrodus în rulare prin deblocare automată. Acest task va 
poziționa, mai întâi, la o valoare nenulă componenta status a 
blocului rendez-vous în cauză, va aduce componenta contor la 
zero, iar apoi va debloca, pe baza cozii, toate celelalte taskuri 
blocate în așteptarea întâlnirii. Deblocarea se efectuează prin 
apelul funcției _wakeup(), repetat de câte ori este necesar. 
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Componenta contor a blocului este adusă la zero de către 
taskul deblocat în mod automat, pentru a se asigura pentru 
taskurile pe care el le deblochează posibilitatea de a se 


autolocaliza în situația a treia. 


A treia situaţie, caracterizată prin valoare nulă a 
componentei contor şi valoare nenulă a componentei status, 
este proprie taskurilor oarecari, deblocate de către partenerul 
lor refăcut rulabil în mod automat, în cazul eşuării întâlnirii 
prin expirarea timpului afectat pentru realizarea ei. Acestor 
taskuri nu le-a mai rămas altceva de făcut, decât să înscrie în 
câmpul fo din contextul lor logic valoarea variabilei status, 
să-şi încheie secțiunea critică executând directiva _unlock() şi 
să părăsească funcţia _rv_ signal) 


Textul funcţiei _rv_signal() este redat în figura 7.3.4_8. 


void _rv_signal (uschar rvid) ( 
RENDEZ_VOUS *rv; 
uschar k; 
_lock() ; 
rv=&_rvlrvid] ; 
rv->contor--; 
i£ (! (rv->contor) ) 4 
rv->status=0; 
while (rv->pie!=& (rv->coada [0])) ( 
rv->pie--; 
k=* (rv->pie) ; 
* (rv->pie) =MAX_ISK; 
_makeup (k) ; 


(se continuă) 


Fig, 7.3.4_8. Textul funcţiei _rv_signal(). 
-partea întâi- 
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(continuare) 


16 else 

17 * (rv->pie)=_tsk_crt; 

18 rv->piet+; 7i 

19 _sleep (rv->timeout) ; 

20 i£ (rv->contor) | 

21 rv->status=1; 

22 zxv->contor=0 ; 

23 while (rv->pie!=& (rv->coada [0])) 
24 rv->pie--; 

25 k=* (rv->pie) ; 

26 * (rv->pie) =MAX_TSK; 

27 _wakeup (k) ; 

28 ) 

29 ) 

30 ) 

31 _contlogi_tsk_crt] .to|=rv->status; 
32 _unlock () ; 

33 ] 


Fig. 7.3.4_8. Textul funcţiei _rv_signal(). 
-partea a doua- 


Definit notiunea de bloc rendezvous: Pa 

2); Ce este, în plan practic, un bloc rendez vous? 
3). În ce consistă mecanismul blocurilor rendez-vous? | 
4). Precizaji rolul. "funcției ry_init(). o 

i 9) Descrieți acțiunile funcției _ry înirț). 

i 6). Daţio implementare C pentru neta. ry. iii), 

i 7). Precizaţi rolul functiei _v_create). 

| 8). Deserieţi acțiunile funcţiei. rw. createț). 

i 9). Daţio implementare. C pentru funcția rw. create) 


10). Precizați rolul, funcției _rv. destroy... 
11). Descr iei acțiunile, funcției... destroy). 
C Pem functi 


E Dati o au dei i 
-o „me destroyQ. - 
13). Precizaţi rolul funcgiei rv. , signal). 
- Descrieți acțiunile. funcției. my. » signal). 
. Dați o implementare C peniru functia _ry_signal) 
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REZUMAT 


Se numeşte sincronizare a taskurilor. punerea taskurilor 
într-o anumită relație temporală unele cu altele sau cu diferite 
evenimente Externe: ; 


Sincronizarea este directă. atunci când vizează în mod 
apia unul sau mai multe taskuri. s 


 Sincronizarea este indirectă atunci când vizează unul sau 
mai multe taskuri prin intermediul unui mecanism care doar el 
le cunoaşte în mod concret... : 


nizare se numesc nememorate dacă. devin 
suni adresate unor r asam care nu le 


Se numeşte. eveniment concret un eveniment legat de 0 
Onari ce se desfăşoară ô în t afara} pr ogn: anului 


Se numeste eyenanent abstract un eveniment legat de o. 
operație intrinsecă pi gramului. : 


Se numeşte eveniment perimat un eveniment care. Teja s-a 


Se numeşte e eveniment neper mat un eveniment care încă nu 
s-a -o 
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- Se numesc evenimente simultane evenimentele care au loc 
în acelaşi mo ent de. timp 


Se numesc evenimente concurente evenimentele « care au loc. 


în acel işi interval de. timp. 


Se numesc evenimente. sincrone e acele evenimente între ale 
căror: momente de producere există o relaţie temporala bine 
DU aul pr edictibilă 


Se numi evenimente asincrone e acele e evenimente intreale. 
căr OF momente de. producere ı nu există O relaţie temporală bine 
precizală oea iă ; 


excluderii mutuak 
capitolul 6, in: o 
tablou o =- struci 
_sem[MAX_ SEMI; 
un sel de. Cinci fina. care au monopolul operării 
j SEMAPHORE: S init), 
vait(), 5 signal. 
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Sineronizarea prin semafoare a unui număr de taskuri cu un 
eveniinent concret e se face în felul următor: 
o se alocă câte un semafor pentru fiecare task 
o se převede în rutina de tratare a întreruperii aferente 
evenimentului e câte o directivă _s_signalỌ) asupra 
fiecărui semafor se i 
œ se prevede în. fiecare task implicat o directivă 
-S wait) pe semaforul aferent lui. 


Figura următoare ilustrează o astfel de sincronizare: 


“întrerupere 


o 


KK. did tone EEk i 


RUTINĂ DESERVIRE */ 
ÎNTRERUPERE. A 


SI le le 3898 al ala ó 


Îl s signalo); 
|. _susienaltb); 


-TASK BỌ 


i _s_wait(b, 0) ; 
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„. Sincronizarea prin semafoare a unor taskuri: care 
utilizează în regim concurehțial; ca producători sau 
consumatori, un tampon de date: se Jace: cu ajutorul a. trei 
semafoare, prin aşa-numitele proceduri ale producătorilor şi 
consumatorilor, care, împreună, constituie. ceea ce se 
cheamă modelul producătorilor şi al consumatorilor. 

H AEF HER HHE K ia D e He eHe e E He e He e AE H ia ee e F e TK e KEKE K nai A 


/* MODELUL PRODUCĂTORILOR ŞI CONSUMATORILOR */ 
| [RR RR ARATA ITAA EAI ARI 


/* sematorul s7 se creează cu contorul initializat la. T */ 
/* sematorul $2 se creează cu contorul iniţializat la 0 + 
/* semaforul s3:se creează cu contorul inițializat lan 


H PD. 


VA 


2. execută vu 
/* aşteaptă la semaforul sip i 
/* garantează că nici un task nù execută 
/* secțiune critică de accesare a zonei tampon i 


3.. depune o dată în zona tampon; 


4. execută _s signal (s2); 
/* semnalează că în zona tampon */ 
„/* a. fost depusă o (nouă): dată */ 


5. execută s signal(s1); : 
/* semnalează. că taskul curent şi-a. încheiat */ 
/* secțiunea critică de accesare a zonei. tanipon,*/ 
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e Mecanismul blocurilor ; eveniment. are la buză 


pe ERA E E RER ER AR / i 
- concepiul de bloc eveniment. 


| /* MODELUL PRODUCĂTORILOR ŞI CONSUMATORILOR * 
TA ae iu etnia aia aci iau adio e ata nl : 
Se. numeşte bloc. eveniment un ansamblu format dintr-o 
variabilă booleană B şi o coadă C, asociat cu un. eveniment şi 
supus următoarelor convenţii: 
e valoarea "I! a variabilei semnifică. faptul: că 
evenimentul. “s-a produs, iar valoarea "Qi -că 
evenimentul nu s-a produs 
e la crearea blocului eveniment, se asigură peniru 
variabilă valoarea "0", iar coada se videază 
è când un task ajunge în Stadiul. în care necesită 
sincronizarea cu un eveniment, se  autoblochează şi se 
înscrie în coada de aşteptare. a “blocului eve imeni 
asociat evenimentului. respectiv. 
când evenimentul se Produce, toate taskurile î înscrise 


pe semaforul s7. se crecază cu contorul inițializat la1* 
A semaforul s2 se creează cu contorul iniţializat la 0 */ 
ip semaforul s3 se creează cu contorul inițializat la n $7 


PARA RR RI E AEA A E A A AAE A / 


/k | PROCEDURA CONSUMATORILOR */ 
adi o oua ANI 


i execută. s wait (52, 0); sia 
o aşteaptă la semaforul s2 până când acesta */ 
garantează, că zona. e nu este vidă i, : 


SAS A) A 66 aia a d 


typedef struct 
uschar. coada [MAX + TSK] i 
uschar *pie; i 
"EVENT; 


î 


Au a alea că taskul. curent. şi-a incheiat + 
pi sectiunea critică de accesare, a zonei tampon */ 


para a E a e aaa at 


unde: i En 
`- câmpul. coadaf] Prelonenteora. coada: blocuhii 
"eveniment; 

= câmpul pie este pointerul de intrare / iesire în/din 
coada blocului eveniment. 


Mecanismul blocurilor crimen consistă m: 
“e un tablou de structuri EVENT, _evn[MAX. EVN]; 
e un set de cinci funcţii care: au monopolul: operării 
“asupra structurilor EVENT: 
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A : e init) ; î 
; pe inițializează tabloul de blocuri eveniment 7 


e create) 
reedază un bloc eveniment :/ 


i SE > destroy) 
/* distruge un bloc eveniment * Ho 


e > wait) 
7/* blochează taskul curent Y 
/* în scriindu-l f în coada de aşteptare a evenimentului A 


: e sionul() 
/* semnalează pr řoducerea evenimentului, + 

/* deblocând toate taskurile aflate în aşteptarea hui */ 

-Z în coada blocului eveniment */ 


izarea prin. “blocuri eveniment a unui număr. de 
u eveniment concret e se face în felul următor: 

se ve alocă un bloc eveniment 
în rutina de tratare a intrer uperii aferente 


întrerupere 


(e) 


TSD i 


fi 


ia i 0); EEE SR e e e 
AVEU /" RUTINĂ DESERVIRE. */ 
stea fe ÎNTRERUPERE... */ 
ii e Fe ea ee e ae este e | 
„e signalte); 
|TASK..BO. a : 
e 
! 
_e_wait(e, 0); 
o L 
} 
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GEN NARRER 


he Mecanismul bloet multievenimeni are la” bază 
conceptulde-bloc. multieveniment. 


„Se numeşte bloc multieveniment un: ansamblu format 
dintr- o mulțime de variabile booleene. puse în corespondență 
cu câte un eveniment, 0 funcție logică de. tip ȘI sau de tip SAU 
definită pe această mulțime sau pe o submulțime. a. ei: şi..0 
coadă, și supus următoarelor convenţii: 

e valoarea logică "I" a unei variabile semnifică faptul 
că evenimentul asociat ei s-a produs; iar valoarea "0" 
-contrariul 

o când un task ajunge în sladil. în care: necesită 
sincronizarea cu uñ multieveniment, el specifi îcăă 
configuratia / configuraţiile de evenimente. în care 
rezidă inultievenimeniul, se autoblochează și se îns rig 
în coada de aşteptare. a blocului 
asociat mulievenimentilur respectiv : 


Se numesc : valori active valorile pe ca 
variabilele asociate evenime telelor unui nultieveniment 
pentru ca. functia „logică din defi nirea) acestui i să ia 
valoarea "I" ; pu 


Se defineşte drept configurație de referință pentru functia 
ȘI o instanță a mulțimii de variabile booleene din componență 
blocului multieveniment, în care variabilele ce apar. ca 
argumente pentru. functia SI sunt instantiate la valorile active, 
iar celelalte -la valoarea 0": 


Se defineşte drept configuratie de referință pentru functia 
SAU o instanță. a mulțimii. de: variabile booleene din 
componenta blocului multievenimeni, m care variabilele 
ce apar ca argumente pentru funcția SAU sunt instantiate 
la. complementarele valorilor. active, iar celelalte -la 
valoarea 0: . 
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Se numeşte condiție de sincronizare definită printr-o 
functie ȘI o configurație de evenimente caracterizată prin 
aceea că dacă se anulează în mulfimea de variabile booleene 
corespunzătoare. ei. elementele ce nu apar ca argumente 
pentru funcția ŞI, ceea ce se. obtine este configuratia. de 
referință pentru. functia ȘI. 


Se numeşte condiție. de sincronizare definită printr-o 
functie SAU o configurație de evenimente caracterizată prin 
aceea că dacă se anulează în multimea de variabile booleene 
corespunzătoare ei elementele ce nu apar: ca. argumente 
pentru funcția SAU, ceea ce se obține este aliceva decât 
confi iguraria € de T penti functia SAU. 


eu. FOR. ME la rându-i structură, definită după cum 
urmează: : 


typedef struct{ 
usshort:evntval; 
usshort mask; 
usshort oper; 
FOR ME; 
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unde: s 
©- câmpul evntval este o variabilă dedicată înregistrării 
„configurației dë referință... o 

- câmpul mask este o. variabilă. destinată. mascării 
variabilelor. booleene. (bitilor): care < nu apar. ca 
argumente. în: functia logică: din definirea condiției de 
sincronizare. 

= câmpul. oper. este o variabilă in care'se înregistrează, 
codificat, tipul functiei logice din definirea condiției de 
sincronizare : 

- câmpul nfiee este o variabilă prin care se ar -atăă dacă 
blocul eveniment este alocat sau liber, 


Mecanismul blocurilor multieveniment consistă în: 
“MULTIEVENI, 


o un tablou | de 


Structuri 
PAMA Na ; SA 


„ne. = cread ; 
/* creează un bloc multieveniment *⁄ 


me destroy 
/* distruge un bloc multieveniment */ 


me. mai) 
/* blochează tashkul curent. */ 
£ < nseriindu, L în coada de aşteptare a muliievenimentului */ 


me > signal). 
/* semnalează producerea multieveniimentuilui, %/ 
/* deblocând toate taskurile aflate în aşteptarea lui: 
/* în coada blocului multievenimeni */ 
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e Mecanismul blocurilor “yendez-vous?. are la bază 
conceptul. de. boc rendez-vous o ; 


/ Se numeşte bloc rendez-vous + un Sola formai dintr-o 
variabilă durează cu rol de contor. şi. o coadă de aşteptare, 
SUPUS următoarelor convenții: : m ` 

Í 9 contor ul indică, inițial, numărul taskurilor care 

| trebuie să se întâlnească, iar curent, numărul 

taskurilor care încă nu au ajuns la întâlnire. 
e coada serveşte înregistrării taskur. ilor care au i ajuns 
deja la întâlnire, blocându-se, cu această ocazie, în 

l teptăi ea celorlalte 

e dată când un task ajunge la întâlnire, 

i se decrementează cu o- unitate. 


d rementări succesive, a. valorii 
râlnirea.a_avut loc. în 
al deblocarea, pe baza 


structură 


maaae structi 
uschar contor; 
` uschar coada [MAX_TSK] i: 
uschar pie; ; 
usint. timeout; 
uschar status; 
„JRENDEZ_ VOUS; 


242 


unde: i 
Sa câmpul contor reprezintă contorul: blocului: rendez 
VOUS. 
- câmpul coada] repreziniă coada blocului. rendez 
yous 
- câmpul: pie reprezintă pointerul de. intrare Ji ieşire 
în/din coadă i 
„= câmpul timeout “reprezintă o variabilă dedicată 
o fixării. unui timp limită pentru realizarea niâlnirii 
- câmpul status reprezintă o variabilă dedicată 
indicării modului în care se finalizează tentativa. de 
rendez vous. i 


- Mecanismul cu ilo; rendez vo s consistă în 
o un tablou. E 
_ru [MAX RVI 
e un sel de pal 


"asupra stru 


ry create) : : 
/ , creează un 1 bloc. rendez vous A 


n. destroy) 
distr: uge un 1 bloc rendez vous */ 


-o EV , signal) 
/* anunță sos la“ ‘rendez-vous ” a taskului curent; */ 
IE dacă i nu toale celelalte taskuri vizate sunt sosite, */ 
/* atunci taskul curent se blochează: 7 
~ alfel are loc deblocarea tuturor taskurilor blocate */ 
i An aşteptarea întâlnirii */. 
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ÎNTREBĂRI: 


1). Cese întelege prin sincronizare a taskurilor? 
2). Când se spune că s incronizarea este directă? 
3. Când se spune că sincronizarea este indirectă? 
4). Ce se înțelege prin cer eri de sincronizare) 
: „nememorate! i | 
5). Ce se înțelege. prir in cereri de sincronizare] 
ia memorate? -o 
6). Cese întelege prin eveniment? 
7). Ce se întelege pr in eveniment concret? 
3). G se înțelege, prin eveniment abstr act? 
ein elege prin eveniment, perimat?. 
eveniment neper imat? 
ine eve imente simultane? 


i stă mecanismul semafoarelor? 
Care sunt cele mai comune e d 
„mecanismul | 


-S 


sincronizare rezolvate u 
m semafoarelor? : | 
15). Cum. se face. sincronizarea. a pr in semafoare a unui) 
număr de taskuri cu un eveniment. concret e? 
. Prezentafi procedura producătorilor din modelul 
şi consumatorilor. | i 
. 20). Pre ezentați procedura. consumatorilor din modelul 
producătorilor şi consumatorilor. 
20). Defi îniți no] unea de bloc even nent. 
22). Ce este, în plan practic, un bloc eveniment? . 
. . 23). h ce consistă mecanismul blocurilor eveniment? 
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$ 
£ 
$ 
: 
$ 
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.. Precizaţi rolul funcției... e int). 

- Deserieţi acțiunile funcției e. initQ. 
,. Dario implementare € pentru funcția. e.n. 

. Precizaţi rolul functiei e createQ: 

. Descrieți acțiunile funcţiei .. e. creare). 

-Dați o implementare C pentru funcția: e create): 
.. Precizaţi rolul funcţiei e: destroy). 

.. Descrieţi acțiunile funcției e. destroy. 

.. Daţi o implementare C pentru funcţia e destroy. | 
... Precizaţi rolul functiei e wat). | 
. Descrieți acțiunile funcției. e. waâilQ. 

; Daji o implementare C pentru funcția e. wait). 
. Preca 
i Descrieți actiunile funcției e  sienal). i 
. Dati o iti ai c pentru oaie 


. Ce avantaje. p 


. Ce dezavantaje. p 
eveniment? i 
). Definiţi notiunea de bloc multieveniment 
. Cese întelege prin valori active? 


. Ce se înțelege. prin : configurație de referință 


. Ce se întelege prin condiție de sincronizare 
defi nită printr-o funcție SI? i 
. Ce se înțelege prin condiție "de. sincronizare 


: Ce este, în plan practic, un bloc multieveniment? 
; În. ce consistă 
: multieveniment? 


rolul functiei e signal). 


e veniment concret 


eveniment? 


Ce se întelege prin. configuratie de referință) 
pentru functia ŞI? : | 


pentru funcfia SAU? 


defi înită printr-o functie SAU? 


mecanism ul blocur ilor 
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50). Precizaţi rolul. funcției me initỌ. 
51). Descrieți acțiunile funcției _me > init). 
52). Dati o implementare C pentru functia —. me > initỌ. 
53). Precizaţi rolul funcției _me_createQ)... 
54). Descrieți acțiunile Juncfiei __me. > create). 
55). Dati o implementare C penn u - funcția 
— _me create). o : 
56). Precizați rolul funcției _me dese) 
37). Descrieți acțiunile funcției me. destroy. ; 
58). Dati o implementare C penin u funcția 
-o me > destroy0. o 
59). Precizați rolul Junna me. wako.. 
60). Descrieti acțiunile funcției ine. ao. 
61). Daţi o implementare C pentr u funcția me. _wait(). 
p Precizaţi rolul funcției me signal. 
). iefi acțiunile, functiei ine  signal(). 
mplementare C pentru funcția 


rezintă mecanismul... blocurilor! 


rezintă mecanismul blocurilor] 
ltieveniment? 

Jefi îniți noțiunea de bloc rendez-vous? 

Ce este, în plan practic, un bloc rendez-vous? 
69). În ce consi mecanismul blocurilor rendez-vous? 
Pr ecizați rolul funcției ry > initỌ. 

fi acțiunile funcţiei. vint). 
mplementare E pen u Pn ry »_initQ). 


76). Ri izaţi rolul fani ry ad : 
77). Descr ieţi acțiunile fuincției__rv destroy). 
) Daţi o implementare c penini u „juma 
ry_destroy0. 
Pr 'ecizafi r olul funcției 
. Descrieți actiunile funct ry signal. 
Daţi o implementare C pentr u funcția n. y signal). 
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8 
COMUNICAREA ÎNTRE 
TASKURI 


8.1. Preliminarii 


Prelucrarea datelor în regim multitasking nu poate fi 
imaginată fără a presupune existența unor schimburi de 
informaţii între taskurile ce consituie un program. Desigur, 
sincronizarea taskurilor înseamnă, în ultimă instanță, un 
schimb de informații între taskuri. Aceste informații sunt, 
însă, extrem de sărace în conținut, cle reprezentând 
doar simple semnale de activare / dezactivare, respectiv de 
deblocare / blocare. 


Prin noțiunea de comunicare între taskuri se desemnează un 
schimb de informaţii în care sunt antrenate atât semnale de 
sincronizare, cât şi alte date. 

Pentru facilitarea realizării comunicării, este necesară 
existența unor mecanisme specifice în componența 
executivelor. Le vom aborda, în continuare, pe cele mai 
eficiente şi uzuale. 


8.2. Comunicarea prin conducte 


O conductă este un tampon circular gestionat după 
principiul FIFO, asociat unei perechi de taskuri dintre care 
unul are rolul de producător, iar celălalt -rolul de consumator. 
Producătorul depune datele în tampon, octet cu octet, iar 
consumatorul le extrage, de asemenea octet cu octet, indiferent 
de ce tip ele sunt [20]. 
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Mecanismul de comunicare prin conducte trebuie să asigure 
blocarea taskului producător, când acesta ajunge în faţa unei 
operaţii de scriere iar tamponul este plin, respectiv blocarea 
taskului consumator, când acesta ajunge în fața unei operaţii de 
citire, iar tamponul este vid. 


Nici un fel de restricții privind lungimea datelor vehiculate 
nu intervin la comunicarea prin conducte; datele care nu încap, 
în întregul lor, în tampon, sunt transmise şi recepționate 
fragmentar, 


Pentru implementarea mecanismului de comunicare prin 
conducte, se introduce tipul de dată pe care îl denumim PIPE, 
cuprinzând: 

o variabilă de tipul uschar, denumită ifp, destinată 
înregistrării indexului taskului producător 
o variabilă de tipul uschar, denumită itc, destinată 
înregistrării indexului taskului consumator 
o variabilă de tipul usint, denumită rs, cu rolul de a 
indica, atunci când are o valore nenulă, pe de o parte, 
faptul că taskul producător s-a blocat, găsind conducta 
plină, iar pe de altă parte, numărul octeților ce au mai 
rămas de scris 
o variabilă de tipul sint, denumită rc, cu rolul de a 
indica, atunci când are o valoare nenulă, pe de o parte, 
faptul că taskul consumator s-a blocat, fie pentru că a 
găsit conducta vidă, fie pentru a-i permite taskului 
producător. să transmită ultimul fragment al unei date, 
iar pe de altă parte, numărul octeților ce au mai rămas 
de citit 
- o variabilă de tipul usshorz, denumită nocumul, 
destinată înregistării numărului de octeți cumulați la un 


moment dat în conductă 

- o variabilă de tipul tablou de caractere fără semn, 
denumită tampon, destinată implementării conductei 
propriu-zise prin care are efectiv loc comunicarea 
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- o variabilă de tipul pointer către un caracter fără semn, 
denumită ps, destinată utilizării în procesul de scriere 
în tampon 

- o variabilă de tipul pointer către un caracter fără semn, 
denumită pc, destinată utilizarii în procesul de citire 
din tampon. 


Considerând dimensiunea conductei - -mai exact: 
dimensiunea tamponului- desemnată prin identificatorul 
DIM_COND, tipul de dată PIPE se va declara așa cum se arată 
în figura 8.2_1. 


i typedef struct{ 
uschar itp; 
uschar itc; 
usint rs; 
usint rc; 
usshort nocunul ; 
uschar tampon [DIM_COND] ; 
uschar *ps; 
uschar *pc; 
)PIPE; 


Fig. 8.2_1. Declararea tipului de dată PIPE. 


Executivul va fi înzestrat cu un tablou de structuri de tipul 
PIPE, pe care îl denumim _pp/], desemnându-i dimensiunea 
prin identificatorul MAX_PP -a se vedea figura 8.2 2. 


PIPE _pp[MAX_PP] ; 


Fig. 8.2_2. Declararea tabloului de structuri conductă _pp/7. 


Este de subînțeles că declaraţia de mai sus trebuie să apară în 
afara oricăror acolade, fiind necesar ca tabloul _pp// să aibă 
statut de variabilă globală, deci: să fie cu locare statică în 
memorie. 
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O structură conductă anume, va fi exploatată cu ajutorul 
indicelui său în cadrul tabloului _pp//. Pentru sugestivizarea 
referirilor, se va introduce câte un identificator adecvat, 
corespunzător fiecărui indice. 


Referirile la o structură conductă sunt permise doar prin 
intermediul unor funcţii ale executivului. Aceste funcții suni 
prezentate, rezumativ, în figura 8.2_3. 


void _p_init (void) 
iniţializează tabloul _pp/J, prin atribuirea valorii NULL 
componentelor ps şi pc, respectiv a valorii MAĂ_7SK * 
/* componentelor itp şi ie ale tuturor elementelor sale */ 


| void_p_create(uschar *ppidădr, uschar prod, uschar cons) 
/* alocă taskurilor prod, cu calitatea de producător, */ 
/* respectiv cons, cu calitatea de consumator, */ 
/* un element al tabloului _pp// şi returnează indicele-i */ 
/* prin variabila pointată de ppidadr */ 


void _p_destroy(uschar ppid) 
/* dezalocă elementul tabloului _pp// cu indicele ppid, */ 
/* repunându-l la dispoziţia funcţiei _p_create() */ 


void_p_send(uschar ppid, void *pdata, usint Idata) 
depune în tamponul structurii conductă cu indicele ppid */ 
/* cei Idata octeți ai datei pointate de pdala */ 


void _p_receive(uschar ppid, void *pdata, usint Idata) 
extrage din tamponul structurii conductă cu indicele ppid 
/* un număr de ldata octeți */ 
/* şi îi atribuie datei pointate de pdata */ 


Fig. 8.2_3. Funcţiile mecanismului de comunicare prin conductă. 
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Funcţia _p_inif() 


Această funcţie are rolul de a iniţializa tabloul de structuri 
conductă, prin stabilirea valorii NULL pentru componentele ps 
şi pc, respectiv a valorii MAX_TSK pentru componentele itp şi 
itc ale tuturor elementelor sale. 


Textul C al funcţiei _p_init() este redat în figura 8.2_4. 


1 void _p_init (void) ţ 
2 PIPE *p; 

3 uschar j; 

4 _lock () ; 
5 
6 
? 
8 


i p=&_ppl[0]; 
i for (j=0;j<MAX_PP; j++) 4 | 
| p->ps=NULL; i 
i p->pc=NULL ; i 
i 9 p->itp=MAX_TSK; i 
i 10 p->itc=MAX_TSK; | 
| 11 ptt: i 
12) | 
13 _unlock () ; i 
i 
i 
Li 


Fig. 8.2_4. Textul funcţiei _p_init(). 


Funcţia _p_creafe() 


Funcţia _p_create() are rolul de a identifica un element liber 
al tabloului de structuri conductă şi de a-l aloca perechii 
producător-consumator specificată prin argumentele sale, 
returnând indicele respectivului element prin variabila pointată 
de argumentul său ppidadr. De asemenea, funcției 
_p_create() îi revine sarcina de a poziționa pointerii ps şi pc ai 
structurii conductă alocată pe primul element al tabloului 
tampon[] din cadrul acesteia. 


Textul C al funcţiei _p_create() este redat în figura 8.2_5. 
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void _p_create (uschar *ppidadr, 
uschar prod, uschar cons) [ 


1 

2 

3 PIPE *p; 

4 uschar j; 
5 _lock () ; 

6  p=& ppi0l; 
7 

8 

9 


3=0; 
while ( (p->ps !=NULL) && (j<MAX_PP) ) ( 
ptt; 

10 TI 

1i } 

12 if(j<MAX_PP){ | 

13 p->itp=prod; i 

14 p->ite=cons; i 
i 15 p->rs=0; H 
16 p->rc=0; 
i 17 p->nocumul=0 ; | 
| 18 p->ps=& (p->conducta[0]) ; i 
| 19 p->pc=& (p->conducta[0]) ; i 
20 } | 
| 21 elsel i 
i 22 abort ("Eroare in taskul $2d: Tentativa | 
| 23 de a crea mai mult de MAX PP ($2d) | 
| 24 conducte!", _tsk_crt, MAX PP); i 
| 25 } l 
| 26 *ppidadr=j; i 
| 27 _unlockţ); i 

28 } i 


Fig, 8.2_5. Textul funcției _p_creare(). 


Funcţia _p_destroy() 


Funcţia _p_destroy() are rolul de a dezaloca elementul 
tabloului de structuri conductă _pp//, al cărui indice este 
precizat prin argumentul său. Dezalocarea consistă în atribuirea 
valorii NULL pentru componenta ps a respectivului element şi 
a valoarii MAX_TSK pentru componentele itp şi itc. In acest 
fel, elementul în cauză este lăsat la dispoziția funcției 
_p_create(), în vederea unei noi alocări. 


222 


Textul funcţiei _p_destroy() este redat în figura 8.2_6. 


1 void p destroy(uschar ppid) 
2 PIPE *p; 

3 _lock () ; 

4 p=e pplppid]; 

5 if (p->rs| |p->rc) | 
6 

7 

8 

9 


abort ("Eroare in taskul %2d: Tentativa 
de a distruge o conducta (%2d) 
nevida!", _tsk crt, ppid); 
) 


10 else 
IL p->ps=NULL; 
12 p->itp=MAX_TSK; i 
13 p->âte=MAX_TSK; | 
14 ) | 
| 15  _unlockţ); 
i i 


16 ) 


Fig. 8.2_6. Textul funcției _p_destrov(). 


Funcţia _p_send(); 


Funcţia _p_send() asigură depunerea în tamponul structurii 
conductă cu indicele precizat prin argumentul ppid a unui 
număr de /data octeți ai datei pointate de argumentul para. 


Pentru a fi posibilă comunicarea datelor de orice tip de la un 
task la altul, argumentul pdata este un pointer generic; în 
cadrul funcţiei, el va fi convertit în pointer de caracter fără 
semn Şi utilizat ca atare. 


Când funcția _p_send() constată că tamponul este plin, ea 
procedează astfel: 
- înregistrează în componenta rs a structurii conductă 
numărul de octeți pe care îi mai are de transmis, pentru 
a-l face cunoscut funcției _p_receive(), prevăzută în 
taskul consumator 
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verifică dacă taskul consumator este blocat în interiorul 
funcţiei _p_receive(), ca urmare a faptului că a găsit 
tamponul vid, şi, în caz afirmativ, îl anunţă că situația 
s-a schimbat în această privinţă şi îl deblochează 
blochează taskul în care ea se execută (taskul 
producător), lăsându-l în aşteptare pasivă a deblocării 
de către taskul consumator. Taskul consumator asigură 
deblocarea producătorului -dacă şi numai dacă îl 
găseşte blocat la tampon plin-, cu ocazia execuţiei 
funcţiei _p_receive() prevăzută în cadrul lui, atunci 
când în tampon este creat suficient spațiu liber pentru 
depunerea tuturor octeţilor de transmis rămaşi restanți 
sau, oricum, atunci când această funcție găseşte 
tamponul vid sau termină de preluat o dată. 


Când termină de pus o dată în tampon, funcţia _p_send() 
verifică dacă taskul consumator este blocat din cauză că a 
întâlnit tamponul vid şi, în caz afirmativ, îl anunţă că tamponul 
nu mai este vid şi îl deblochează. 


Textul C al funcţiei _p_send( este redat în figura 8.2_7. 


1 
2 
3 
4 
5 
6 
7 
8 
9 


10 


void _p_send(uschar ppid, void *pdata, 
usint ldata) ţ 
PIPE *p; 
uschar *q; 
usint nos; 
_lock(); 
p=&_pp[ppid] ; 
if (_tsk _ert!=p- >itp) £ 
abort ("Eroare in taskul 324; taskul 
curent nu este asociat drept 
producator la conducta $2d!", 
_tsk_crt, ppid) ; 


Fig. 8.2_7. Textul functiei _p_send(Q. 
-partea întâi- 
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i (continuare) că 
i d 190 2 pt 
; 14 ekse{ 
15 q=({uschar *)pdata; 
16 nos=ldata; 
17 while (nos) 1 
18 if (p->nocumul<DIM_COND) { 

19 *p->ps=*q++; _ 

i 20 if (p->ps== 

i 21 & (p->tampon [DEM _COND-1])) 4 

i 22 p->ps=t& (p->conducta [0]) ; 

î 23 } 

: 24 else{ 

7 25 p->ps+t; 

“ 26 ) 

Z i 27 nos--; i 
i 28 p->nocumul++; | 
| 29 ) } 
i 30 else{ 

i 31 p->rs=nos; 
i 32 if (p->rc) 
33 p->re=0; 
i și 3 _wakeup (p->itc) ; 

$ 35 } 

i i 36 while (p->rs) 4 

j 37 _sleep (0); 

4 38 ) 

| 39 ) 
40 ) 
41 i£ (p->rc) | 
42 p->rc=0; 
43 _wakeup (p->itc) ; 
44 } 
45 } 
46 _unlock(); 
41) 


Fig. 8.2_7. Textul functiei _p_send(). 
-partea a doua- 
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Funcţia p_receive() 


Funcţia _p_receive() asigură extragerea din tamponul 
structurii conductă al cărui indice este precizat prin argumentul 
ppid a unui număr de ldata octeți şi atribuirea lor variabilei 
pointate de argumentul pdata. 


Pentru a fi posibilă comunicarea datelor de orice tip de la un 
task la altul, ca şi în cazul funcției _p_send(), argumentul pdata 
este un pointer generic; în cadrul funcţiei, el va fi convertit în 
pointer de caracter fără semn şi utilizat ca atare. 


Pe parcursul extragerii octeţilor din tampon, funcția 
_p_receive() verifică, utilizând componenta rs a structurii 
conductă, dacă taskul producător este blocat în interiorul 
funcţiei _p_send(), ca urmare a faptului că a găsit tamponul 
plin. În caz afirmativ, când se ajunge ca în tampon să fie 
suficient spaţiu liber pentru depunerea tuturor octeţilor rămaşi 
restanţi, funcţia _p_receive() anunță taskul producător asupra 
acestui lucru şi îl deblochează, înregistrând în componenta rc a 
structurii conductă numărul octeţilor neextraşi ai datei curente 
și blocând taskul în care ea se execută (taskul consumator). 


Când funcţia _p_receive() constată că tamponul este vid, 
procedează astfel: 

- înregistrează în componenta rc a structurii conductă 
numărul de octeți pe care îi mai are de recepționat; 

- verifică dacă taskul producător este blocat în interiorul 
funcției _p_send() ca urmare a faptului că a găsit 
tamponul plin şi, în caz afirmativ, îl anunţă că situația 
s-a schimbat în această privință și îl deblochează; 

- blochează taskul în care ca se execută (taskul 
consumator), lăsându-l în aşteptare pasivă a deblocării 
de către taskul producător. Taskul producător asigură 
deblocarea consumatorului, dacă îl găsește blocat la 
tampon vid, cu ocazia execuţiei funcției _p_send() 
prevăzută în cadrul lui, atunci când această funcție 
găsește tamponul plin sau termină de depus o dată. 
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Când termină de extras o dată din tampon, funcția 
_p_receive() verifică dacă taskul producător este blocat din 
cauză că a întâlnit tamponul plin şi, în caz afirmativ, îl anunță 
că tamponul nu mai este plin şi îl deblochează. 


/ Textul Cal funcţiei _p_receive() este redat în figura 8.2_8. 


void p receive (uschar ppid, void *pdata, 
T usint ldata){ 
PIPE *p; 
uschar *q; 
usint noc; 
_lock() ; 
p=e_pelppid] ; 
if (_tsk ert!=p->itc) 4 
abort ("Eroare in taskul %2d: taskul 
curent nu este asociat drept 
consumator la conducta $2d!", 
_tsk_cert, ppid); 


DUNA 


[es EES e 


) 
else{ 
q= (uschar *)pdata; 
noc=ldata ; 
while (noc) { 
if (p->nocumul) { 
*q++=tp->pe; 
if (p->pe== 
& (p->tampon [DIM _COND-1]) ) $ 
p->pc=& (p->conducta [0]) ; 
} 
else{ 
p->pce++; 
) 
noc--; 
p->nocumul--; 
if (noc&t (p->rs) && (p->rs<= 
(DIM_COND- (p->nocumul) ) ) ) { 
p->rc=noc; 
p->rs=0; 
_makeup (p->itp) ; 
hile (p->rc) í 
_sleep (0); 


_p_receive(). 
-partea întâi- 
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i 
i 
j 
li 
i 
i 
li 
i 
i 
li 
i 
i 


55 
56 


p->rc=noc; 

if (p->rs){ 
p->rs=0; 
_wakeup (p->itp) ; 


) 

while (p->rc) | 
_Ssleep (0); 

} 


} 
if (p->rs) | 
p->rs=0; 
_Wakeup (p->itp) ; 
) 
) 


_unlock () ; 


) 


ig. 8.2_8. Textul funcţiei p_receive Ø. 
-partea a doua- 


ÎNTREBĂRI: 


1). Definiţi noțiunea de conductă. 

2): Ce este, în plan practic, o conductă? 

3). În ce consistă mecanismul conductelor? 

4); Precizați rolul functiei. p. iînit). 

5). Descrieți acțiunile funcției. .p_initQ). 

6). Dati o implementare C peniiu funcția -p_-init(). 

7)... Precizaţi rolul functiei: p-.ereateQ. 

5). Descrieți acțiunile funcţiei. p_createQ. 

9): Daţi o implementare. C pentru funcția -p_createQ.. 


10): Precizați rolul functiei p_destrov(). 
11): Descrieti acțiunile functiei -.p. destroyQ. 
12): Däļi o implementare C pentru functia p. destroy. 
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13). Precizati rolul funcției p- receive(). 

14). Descrieți actiunile funcției -p.receiveQ. 

15). Daţi o implementare C pentu functia -:p_receiveQ): 

16). Precizati rolul funcției ..p.:sendQ. 

17). Descrieți acțiunile funcției p-sendỌ: 

18). Daţi o implementare. Cpentru funcția: p :sendQ): 

19). Cum. se. asigură comunicarea prih. mecănismul) 
conchicteloi? i | 

20). Ce avantaje prezintă mecanismul: conductelor? 

21). Ce dezavantaje prezintă mecanismul conductelor? 


8.3. Comunicarea prin cutii poştale 


O cutie poștală reprezintă o structură al cărei element central 
este un tampon circular (gestionat după principiul FFO) în 
care orice task poate scrie informaţii de un anumit format, 
invariabil, accesibile în citire oricărui alt task şi reprezentând 
descriptori ai unor date. 


Cel mai frecvent, descriptorii vehiculați prin cutii poștale 
cuprind pointerul datei ce se comunică, lungimea datei și 
indexul taskului ce o produce. 


Mecanismul de comunicare prin cutii poştale trebuie să 
asigure blocarea taskurilor producătoare, când acestea ajung în 
faţa unei operaţii de scriere iar tamponul este plin, respectiv 
blocarea taskurilor consumatoare, când acestea ajung în fața 
unei operații de citire iar tamponul este vid. 


Scrierea în şi citirea din tampon reprezintă secțiuni critice. 
Este evident, mecanismul de comunicare prin cutii poștale 
funcționează după modelul producătorilor şi al consumatorilor. 
Operaţiile de sincronizare care fac obiectul acestui model sunt 
intrinseci mecanismului, împreună cu operaţiile de depunere, 
respectiv de extragere a descriptorilor în / din tampon. Așadar, 
mecanismul asigură degrevarea utilizatorului de sarcina 
aplicării explicite a modelului producătorului şi 
consumatorului. 
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Pentru implementarea mecanismului de comunicare prin 
cutii poştale, se introduce tipul de dată DESCRIPTOR, care 
cuprinde: 

- o variabilă denumită pd, de tip pointer generic către 
data de comunicat 

- o variabilă denumită ld, de tipul usini, reprezentând 
lungimea datei de comunicat 

- o variabilă denumită ip, de tipul uschar, reprezentând 
indexul taskului producător. 


Tipul de dată DESCRIPTOR se va declara, deci, astfel: 


typedef struct 
void *pd; 
usint id; 
uschar ip; 

} DESCRIPTOR; 


Fig. 8.3_1. Declararea tipului de dată DESCRIPTOR. 


Având în vedere cele menționate la prezentarea modelului 
producătorului și al consumatorului, pentru implementarea 
mecanismului de comunicare prin cutii poştale se va introduce, 
de asemenea, tipul de dată MAILBOX, în compoziţia căruia 
intră: 

- o variabilă denumită s7, de tipul SEMAPHORE, 
destinată realizării excluderii mutuale (contorul 
semaforului s7 se va inițializa la valoarea 1); 

- o variabilă denumită s2, de tipul SEMAPHORE, 
destinată controlului operațiilor de citire din. tampon 
(contorul semaforului s2 se va inițializa la valoarea 0); 

- o- variabilă denumită s3, de tipul SEMAPHORE, 
destinată controlului operațiilor de scriere în tampon 
(contorul semaforului s3 se va ițializa la o valoare egală 
cu dimensiunea tamponului); 

- o variabilă “ablou, denumită buff], de tipul 
DESCRIPTOR, reprezentând tamponul propriu-zis; 

- o variabilă denumită ps, de tipul pointer către un 
DESCRIPTOR, destinată utilizării în procesul de 
scriere în tampon; 
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- o variabilă denumită pc, de tipul pointer către un 
DESCRIPTOR, destinată utilizării în procesul de citire 
din tampon. 


Considerând dimensiunea tamponului specificată prin 
identificatorul DIM_CP, tipul de dată MAILBOX se va declara 
astfel 


typedef struct 
SEMAPHORE sl; 
SEMAPHORE s2; 
SEMAPHORE s3; 
DESCRIPTOR buf [DIM CP]; 
DESCRIPTOR fps; 
DESCRIPTOR *pc; 

YMAILBOX; 


fig. 8.3_2. Declararea tipului de dată MAILBOX. 


Executivul va fi înzestrat cu un tablou de structuri de tipul 


MAILBOX, pe care îl denumim _mb//, specificându-i 
dimensiunea prin identificatorul MAX_MB. Declararea acestuia 
se face aşa cum se arată în figura 8.3_3. 


MAILBOX _mib [MAX MB] ; 


Fig. 8.3_3. Declararea tabloului de cutii poștale 0/7. 


Este de subînțeles că declarația de mai sus trebuie să apară în 
afara oricăror acolade, fiind necesar ca tabloul _mb//7 să aibă 
Statut de variabilă globală, deci: să fie cu locare statică în 
memorie. 


O cutie poştală anume va fi exploatată cu ajutorul indicelui 
său în cadrul tabloului _mb//, introducând câte un identificator 
pentru fiecare indice. 


Pentru facilitarea înțelegerii mecanismului de comunicare 
prin cutie poştală, se oferă în figura 8.3 4 o reprezentare 
sinoptică a întregii structuri de date utilizate. 


231 


CAP. 8. COMUNICAREA ÎNTRE TASKURI 


sl 

short contor; 
uschar coadaf]; 
uschar *pi; 
uschar *pe; 
uschar valinit; 


short contor; 
uschar coada[]; 
uschar *pi; 
uschar *pe; 
uschar valinit; 


short contor; 
uschar coada[]; 
uschar *pi; 
uschar *pe; 
uschar valinit; 


buf[0] 

void *pd; 
usint ld; 
uschar ip; 


buf[DIM_CP-1] 
void *pd; 
usint Id; 
uschar ip; 


ps 
DESCRIPTOR *ps; 


pc 
DESCRIPTOR *pc; 


_mb[0) 


sl 


short contor; 
uschar coada[j; 
uschar “pi; 
uschar *pe; 
uschar valinit; 


short contor; 
uschar coada[]; 
uschar *pi; 
uschar *pe; 
uschar valinit; 


s3 


short contor; 
uschar coadu[]; 
uschar *pi; 
uschar *pc; 
uschar valinit; 


buff0] 


ps 


void *pd; 
usint ld; 
uschar ip; 


but[DIM_CP-1} 


void *pd,; 
usint ld; 
uschar ip; 


DESCRIPTOR *ps; 


pe 


DESCRIPTOR *pc; 


_mb[MAX_MB-1] 


Fig. 8.3_4. Structura de date a mecanismului de comunicare 
prin cutii poştale -reprezentare sinoptică. 


SN 


CAP. 8. COMUNICAREA ÎNTRE TASKURI 


Comunicarea prin cutii poştale este instrumentată cu ajutorul 
setului de funcții prezentate, grupat, în figura 8.3_5. 


void _mb_init(void) 
/* ințializează tabloul _mb/] prin atribuirea valorii NULL */ 
/'* componentelor ps ale elementelor sale */ 


void _ mb_create(uschar mbidadr) 
/* alocă un element al tabloului _n0// */ 
/* şi furnizează indicele-i */ 
/* prin variabila pointată de mbidadr */ 


void __mb_destroy(uschar mbid) 
/* dezalocă elementul tabloului _+nb// cu indicele mbid, 
/* repunându-l la dispoziţia funcției _mb_create() */ 


void _mb_send(uschar mbid, void *pdata, usint Idata) 
/* depune în cutia poştală cu indicele mbid */ 
/* descriptorul corespunzător datei pointate */ 
/*de argumentul pdata, având lungimea, în octeți, */ 
/* specificată de argumentul Idata */ 


|. | void_mb_receive(uschar mbid, void *pdata, uschar *pidacr) 
i /* extrage din cutia poştală cu indicele mbid */ 
/* descriptorul următor, atribuind valoarea variabilei */ 
/* pe care acesta o reprezintă, variabilei pointate */ 
/* de argumentul pdata; furnizează indexul */ 
/* taskului producător prin variabila pointată */ 
/* de argumentul pidadr */ 


Fig. 8.3_5. Funcţiile mecanismului de comunicare prin cutii poştale. 


Această funcţie are rolul de a iniţializa tabloul de structuri 
cutie poștală, prin stabilirea valorii NULZ pentru componentele 


; Funcţia mb_init () 
i ps ale tuturor elementelor sale. 


Textul C al funcției _mb_init() este redat în figura 8.3_6. 
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1 void _mb_init (void) [ 

2 MAILBOX *m; 

3 uschar 3; 

4 uschar i; 

5 _lock (); 

6 m=&_mb [0]; 

7 for(j=0;3<MAX MB;j+t+) ( 
8 m->ps=NULL; 


9 for (i=0;i<MAX_TSK; i++) | 
10 m->s1.coada[i]=MAX_TSK; 
11 m->s2.coada[i]=MAX_TSK; 
12 m->s3.coada[i]=MAX_TSK; 
13 } 
14 m++; 
15 ) 
16 _unlock () ; i 
17) | 


Fig. 8.3_6. Textul funcției _mb_ini(). 


Funcţia _mb_create() 


Funcţia _mb_create() are rolul de a identifica un element 
liber “al tabloului de structuri cutie poştală şi de a-l 
aloca, furnizând  indicele-i prin variabila pointată de 
argumentul mbidadr. 


De asemenea, funcției _mb_create() îi revine sarcina de a 
inițializa semafoarele din componența structurii cutie poştală 
alocată, în conformitate cu rolul lor în cadrul mecanismului de 
comunicare (a se vedea modelul producătorilor şi 
consumatorilor), şi anume: 

- semaforul s7: cu componenta contor la valoarea 1 şi 
componentele pi şi pe la valoarea de pointare a 
elementului 0 al componentei coada/7; 

- semaforul s2: cu componenta contor la valoarea 0 
şi componentele pi şi pe la valoarea de pointare a 
elementului 0 al componentei coada/f; 

- semaforul s3: cu componenta contor la valoarea 
DIM _CP şi componentele pi şi pe la valoarea de 
pointare a elementului 0 al componentei coada/]. 
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În plus, funcția _mb_create() asigură inițializarea 
componentelor ps şi pe ale cutiei poştale alocate la valoarea de 
pointare a elementului 0 al componentei buff} a acesteia. 


Textul funcţiei mb_create() este redat în figura 8.3_7. 


1 void mb create (uschar *mbidadr) { 

2 MAILBOX *m; 

3 uschar j; 

4 lock (); 

5 m=e mb[0]; 

6 j=0; 

7 while ( (m->ps!=NULL) e& (3<MAX_MR) ) ( f 
8 mit; i 
9 jtt; | 
10 } | 
11 if (3<MAX_MB) | i 
12 _mb[3] „sl.contorzl; | 
13 _mb[j].s1.pi=&(_mb[j].s1.coada[0]); | 
14 _mb[j].sl.pe=&(_mbf[j].s1.coada[0]); i 
15 _mb[j].s2.contor=0; f 
16 _mb[j].s2.pi=&(_mb[j].s2.coada[0]); | 
17 _mb[j].s2.pe=&(_mb[j].s2.coada[0]) ; | 
18 _mb[j].s3.contor=DIM_CP; | 
19 _mb[j].s3.pi=&(_mb[j].s3.coada[0]); i 
20 _mb[i] .s3.pe=&(_mb[j].s3.coada[0]); | 
21 m->ps=& (m->buf [0] ) ; i 
22 m->pe=& (m->buf [0] ) ; 

23 ) 

24 elsej 

25 abort ("Eroare in taskul $2d: Tentativa | 
26 de a crea mai mult de MAX MB ($24) i 
27 cutii postale!", _tsk crt, MAX MB); 
28 } 


29 *mbidadr=j ; 
30 _unlock () ; 
31) 


Fig. 8.3_7. Textul funcției _mb_create(). 
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Funcţia _mb_destroy() 


Funcţia _mb_destrov() are rolul de a dezaloca elementul 
tabloului de structuri cutie poştală al cărui indice este precizat 
prin argumentul său, atribuind valoarea VULL componentei 
sale ps. În acest fel, elementul în cauză este lăsat la dispoziţia 
funcţiei _mb_create(), în vederea unei noi alocări. 


Textul C al funcției _mb_destrov() este următoru 


1 void _mb_destroy (uschar mbid) { 
2 MAILBOX *m; 
3 _lock(); 
4 m=&_mb [mbid] ; 
5 if (m->ps !=m->pe) | | 
6 abort ("Eroare in taskul %2d: Tentativa ! 
7 de a distruge o cutie postala (%2d) | 
8 nevida!", _tsk crt, mbid); 
9 } 
0 else 

m->ps=NULL; 
) 


_unlock () ; 


Fig. 8.3_8. Textul funcției _mb_destroy(). 


Funcţia mb_send() 


Funcţia _mb_send() are rolul de a depune în cutia poştală cu 
indicele mbid descriptorul corespunzător datei pointate de 
argumentul pdara, având lungimea, în octeți, precizată de 
argumentul /data. 


În conformitate cu modelul producătorilor şi al 
consumatorilor, depunerea va fi precedată de o secvență de 
instrucții indivizibilă, care execută operaţiile ce definesc 
funcția _s_wait(), asupra semafoarelor 53 şi s7, asigurându-se, 
astfel, evitarea depunerilor în tamponul plin, respectiv 
excluderea mutuală a secțiunilor critice de operare asupra 
tamponului. 
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După depunerea în tampon a pointerului către data în cauză - 
reprezentat de argumentul pdara-, a lungimii datei - 
reprezentată de argumentul Idata- şi a indexului taskului 
producător (care, evident este tocmai taskul în care funcţia se 
execută), se actualizează pointerul de scriere, ținând scamă de 
gestiunea circulară a tamponului. 


În final, o nouă secvenţă de instrucții indivizibilă va executa 
operaţiile ce definesc funcția _s_signal(), asupra semafoarelor 
s2 şi s7, semnalându-sc, astfel, faptul că un nou descriptor a 
fost depus în cutia poştală, respectiv că secțiunea critică s-a 
încheiat. 


Textul C al funcţiei _mb_send() este redat în figura 8.3 


RE RER RR RR RR he de Ae ehe e RARĂ TRI | 
/* funcția mb send() mizează pe declarațiile: */, 


A CR a e ni E DR i a a a să [i 
e typedef structi */| 
| /* short contor; */i 
pa uschar coada [MAX_TSK] ; */j 
| /* uschar *pi; 7 
pr uschar *pe; a 
> uschar valinit; K 
| pe ) SEMAPHORE ; */] 
ET d. A III E OL ENAN LE PERE DELEA EATA */i 
pi typedef struct{ */ i 
> void *pd; */| 
| /* usint 1d; */| 
i /* uschar ip; */i 
| /* }DESCRIPTOR; */i 


/* typedef struct{ x[i 
| Ani SEMAPHORE sl; */i 
/* SEMAPHORE s2; */; 
/* SEMAPHORE s3; */i 
pe DESCRIPTOR buf [DIM CP]; xi 
/* DESCRIPTOR *ps; *7i 
pe DESCRIPTOR *pc; */; 
{$ }MAILBOX; xp 


[* MAILBOX _mb [MAX MB]; */ 
EEETEEEEEEEEEEEEEEEEEEEEEEE FR / 


Fig, 8.3_9. Textul funcției _7nb_send(Q). 
-partea întâi- 
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1 void mb send(uschar mbid, void *pdata, 
2 usshort ldata) j 

3 SEMAPHORE *pl, *p2, *p3; 

4 uschar k; 


5 _lock () ; 

6 pl=&_mb [mbid] .s1; 

7 p2=&_mb [mbid] .s2; 

8 p3=&_mb [mbid] .s3; 

9 if (--p3->contor<0) { 


10 *p3->pi=_tsk_crt; 
11 if (p3->pi==6 (p3->coada [MAX_TSK-1])) | 
12 p3->pi=& (p3->coada [0]) ; 
13 ) 
14 else{ 
15 p3->pi++; 
16 ) 
aa _sleep (0); 
ia 3 
| 19 i£ (--p1l->contor<0) ( 
| 20 *pl->pi=_tsk_ert; 
| 21 if (pl->pi==& (pl->coada [MAX_TSK-1]) ) [ 
| 22 pl->pi=& (pl->coada [0]) ; 
| 23 } 
| 24 else{ 
| 25 pi->pi++; 
| 26 } 
| 27 _sleep (0) ; 


28 } 
29 _mb [mbid] .ps->pd=pdata; 

30 _mb [mbid] .ps->ld=ldata; 

31 _mb [mbid] .ps->ip=_tsk crt; 
32 î£ (_mb [mbid] .ps== 


33 & (_mb[mbid] .buf [DIM Cp-1])) ( 
34 _mb [mbid] .ps=& (_mb [mbid] .bu£[0]) ; 
35 3} 

36 else{ 

37 _mb [mbid] .ps++; 

38 } 


Fig. 8.3_9. Textul funcției _mb_send0. 
-partea a doua- 
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39 i£ (++p2->contor<=0) [ 

40 k=* (p2->pe) ; 

41 * (p2->pe) =MAX_TSK; 

42 if (p2->pe==€ (p2->coada [MAX _TSK-1]) ) ( 

43 p2->pe=& (p2->coada [0]) ; 

44 ) 

45 else{ 

46 p2->pett; 

47 } 

48 _wakeup (k) ; 

49 ) 

50 i£ (++pl->contor<=0) { 

51 k=* (pl->pe); 

52 * (p1->pe) =MAX_TSK; 

53 if (pl->pe==t (pl ->coada [MAX _TSK-1]) ) 4 

54 pl->pe=t (pl->coada [0]) ; 

55 ) | 
| 56 elsef 
i 57 pl->pet+; i 

58 ) i 

59 _wakeup (k) ; | 

6 } | 

61 _unlock () ; | 

| 
i 


62 ) 


Fig. 8.3_9. Textul funcţiei _mb_senul(). 
-partea a treia- 


Funcţia _7nb_receive() 


Funcţia _mb_receive() are rolul de a extrage din cutia 
poştală cu indicele mbid descriptorul următor, atribuind 
valoarea variabilei pe care el o reprezintă variabilei pointate 
de argumentul  pdata. De asemenea, funcția furnizează 
indexul taskului producător, prin variabila pointată de 
argumentul său pidadr. 


Textul funcției _mb_receive() este redat în figura 8.3_10. 
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pe ee e RR E E RR EEE EEE EEEE iaai EEEE EEEE | i 11 if (--p2->contor<0) 4 
pe funcția _mb receive () */; | i 12 *p2->pi= tsk crt; 
pe mizează pe declarațiile: y | i 13 if (p2->pi==& (p2->coada [MAX_TSK-1])){ 
pi KA j 14 2->pi=& (p2->coada [0]) ; E 
pi typedef struct{ */. | i is T pz->p P [0]); 
pi short contor; io ; 16 else{ 
/* uschar coada [MAX _TSK] ; */i i i 17 2->pi++; 
Pai uschar *pi; */ i i 18 A 
/* uschar *pe; */i j ; } 
/* uschar valinit; */| | . i 19 -sleep (0) ; 
/* } SEMAPHORE ; */ i fa 20; i} 
* si! i 21 i£ (--pl->contor<0) | 
/ /i H H 
/* typedef struct{ A E : i 22 *pl->pi=_tsk_crt; 
pr void *pă; */: ; S i i 23 if (pl->pi==& (pl->coada [MAX _TSK-1]) ) ţ 
Ai usint ld; */} i pj 24 pl->pi=& (pl->coada [0]) ; 
pi uschar ip; */j i : i 25 ) 
INA )DESCRIPTOR; xp j i 26 else 
pa TA! il 27 a 
l /k typedef struct{ */ | |. seg i 
/* SEMAPHORE s1; */| i : | | 29 sleep (0); 
i /* SEMAPHORE s2; “i i i 30 } = 
/* SEMAPHORE s3; */} i kei 
i 31 = (char *)pdata; 
An DESCRIPTOR buf [DIM_CP] ; +i | i P=( )P 
; — [i 5 | i 32 q= (char *) (_mb[mbid] .pc->pd) ; 
pi DESCRIPTOR *ps; RAR: i © 33 ldata= mb[mbid ; 
pr DESCRIPTOR *pe; */ | i] a a=_mb [mbid] .pe->la; 
a MATI:BOX; +7 i i i 84 while (Ldata--) ( 
pi $ xp! i | 35 *pt+=*q++; 
| /* MAILBOX mb[MAX_MB] ; */i | 36 } 


37 *pidadr=_mb [mbid] .pc->ip; 


Î poe ee ee e RE e e RER RR RR Rt! i 
ij 38 if(_mb[mbid] .pe== 


1 void mb receive (uschar mbid, void *pdata, i 39 z ( mb[mbid] buf [DIM_CP-1])) 1 
2 uschar *pidadr){ i i — 3 a 
H A i 40 .pc= i ý 
SEMAPHORE *pl, *p2, *p3; i f _mb[mbid] .pc=& (_mb [mbid] .buf[0]) ; 
H 41 } 

uschar k; i jE 1 

usint ldata; i i pi e get să 

char *p, *q; N i i 5 i _mb[mbid] .pet+; 


pl=&_mbimbid] .s1; i H 
p2=6_mb [mbid] .s2; i . i 
p3=&_mb [mbid] .s3; i î i 


e continuă) 


3 
4 
5 
6 
7 _lock () ; H i 
8 i 
9 
0 


1 
Fig. 8.3_10. Textul funcției _mb_receive(). 
-partea a doua- 


Fig. 8.3_10. Textul funcției _mb_receive(). 
-partea întâi- 
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45 if (++p3->contor<=0) | 


46 k=* (p3->pe) ; 

47 * (p3->pe)=MAX_TSK; 

48 if (p3->pe==& (p3->coada [MAX _TSK-1])) ( 
49 p3->pe=& (p3->coada [0]) ; 

50 ) 

51 else 

52 p3->pe++; 

53 } 

54 _wakeup (k) ; 

55 ) 

56 if (++p1->contor<=0) { 

57 k=* (pl->pe) ; 

58 * (pl->pe) =MAX_TSK; 

59 if (pl->pe==& (pl->coada [MAX_TSK-1]) ) ( 
60 pl->pe=& (pl->coada [0]) ; 

61 ) 

62 else 

63 pl->pe++; 


64 ) 
_wakeup (k) ; 


67 _unlock () ; 


D 
in 


Fig. 8.3_10. Textul funcției _mb_receive(). 
-partea a treia- 


În conformitate cu modelul producătorilor şi al 
consumatorilor, extragerea va fi precedată de o secvență de 
instrucții indivizibilă, care execută operaţiile ce definesc 
funcția _s_wait() asupra semafoarelor s7 şi +2, asigurându-se, 
astfel, evitarea extragerilor din tamponul vid, respectiv 
excluderea mutuală a secțiunitor critice de operare asupra 
tamponului. 


După extragerea din tampon a pointerului către data 
recepționată, a lungimii respectivei date şi a indexului taskului 
care a produs-o, are loc copierea datei, octet cu octet, în 
variabila pointată de argumentul pdata, iar apoi, actualizarea 
pointerului de citire, ținând seamă de gestiunea circulară a 
tamponului. 
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În final, o nouă secvenţă de instrucții indivizibilă va executa 
operaţiile ce definesc funcția _s_signal() asupra semafoarelor 
s3 şi si, semnalându-se, astfel, faptul că un nou descriptor a 
fost extras din cutia poştală, respectiv că secţiunea critică s-a 
încheiat. 


1): Definiţi noțiunea de cutie poştală. 
2). Ce este, în plan practic, o cutie poştală? 

3). În ce consistă mecanismul cutiilor poștale? 

4). Precizaţi rolul funcției. mb. înit). 

5): Descrieti acțiunile funcţiei. mb. înit). 

Daţi o implementare C pentru funcția -. mb intg. 
Pr ecizar A rolul Smene mb create). i 


S 


- Descrieti. etil Tai “mb og, E. 
12): Daţi o implementare. © penmi „ funia] 
¿mbi destroy). A : 
13). Precizaţi rolul. funcției mb. recevi. 
14). Descrieti acțiunile functiei: mb: receive: 
15). Daţi. 0. implementare. © pentru - funețial 
mb_receive(). | 
16). Precizaţi rolul funcției mb y sendo): 
17): Descrieți acțiunile funcţiei. mnb._sendQ. 
18). Daţi o implementare C pentu functia ` mb sendo. 
19). Cum se asigură comunicarea: prin -mecănisinil 
cutiilor poştale? 
20). Ce avantaje prezintă mecanismul cutiilor poştale? 
21). Ce. dezavantaje. prezintă. : mecanisinul cutiilor) 
poştale? | 
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ünde: : ; 
- câmpul itp este o variabilă în care se. înregistrează 
indexul taskului producător S 
~- câmpul itc este o variabilă în care se înregistrează 
-indexul taskului consumator i 
- câmpul rs este o variabilă în care se înregistrează 
numărul octeților: unei. date rămaşi nescrişi: datorită 
umplerii conductei 
- câmpul. re este o variabilă. în care: se: înregistrează 
numărul. octeților. unei date onai necitiţi "datorită 
golirii conductei ; ; 
- câmpul: nocumul este o variabilă în care se 
-Înregistrează mimărul octeților cumulati în conductă 
„= câmpul tampon] este un tablou care melen neoa 
‘tamponul mecanismului 
©- câmpul ps reprezintă pointerul: de scriere în tampon i 
= câmpul pe reprezinta pointer. ul de citire din tampon. 


H: Se numeşte comunicare între taskuri ansamblul de actiuni. 
| piin care taskurile îşi oferă date unele altora, respectiv preiau 

date unele de la altele, sincronizânchi-şi în acest sens, în mod 
specific; activitățile: 


penetra 


Principalele mecanisme de comunicare sunt: 
è mecanismul conductelor; 
o mecanismul cutiilor poştale. 


o Mecanismul conductelor are la. be conceptul: de 
conducta. 


Se numeşte conductă un 7 tampon circular (gestionat după i 
principi FIKO), asociat uhei perechi de taskuri dintre care į 


iar celălalt -consumator şi SUpuUs 


când li ajunge. în Mp unei operaţii de! 
citire iar lamponul este vid, are loc blocarea sa 

e când o dată nu încape în tampon în întregul ei, ea este 
. transmisă şi receptionată. fragmentar. 


; o 
/* creează o conductă */ 
"p destroy 


În plan ăclic, o conductă este o structură definită astfel: pi 
PI DACI EER fi gi - /* distruge o conductă */ 


: -p.receiveQ 
/* extrage o dată din conductă imediat sau, “Z 
f dacă aceasta este vidă, după o ) astepta e pasivă T 


5 typedef struct 

© usċhar itp; 
uschar itc; 

"usint'rs; 
usint re; 
usshort nocumul ; i 
uschar tampon [DIM COND 
uschar *ps; ; à 
| uschar *pe; 

JPIPE; 


p: send) 
A depune o dată în conductă imediat sau,*/. 
/* dacă aceasta este plină, după 0 aşteptare pasivă */. 
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è Mecanismul cutiilor. poştale are la bază conceptul: de cutie 
poştală: 
| E o 
Se: ntuneşte. cutie poştală un. tampon circular (gestionat 
|chipă principiul FIEO), în care orice task poate scrie şi din care 
| orice task poate. citi descriplorii datelor. ce jac obiectul 
| comunicării în conformitate cu următoarele conventii: 
| o când producătorul ajunge în faja unei operi ajii. de 
| scriere iar lamponul este plin, are loc blocarea sa 
je când consumatorul ajunge în fata unei operatii de 
Su citire lar tamponul este vid, are loc blocarea sa 


plan practic, o cutie poștală este o structură definită 


cu DESCRIPTOR | la rându-i sir uctură def nită dupa cum 
urmează: 


typedef struct{ 
void xpa; 
usint ld; : 
i uschar ip; 
")DESCRIPTOR; 


unde ua -o : : 
- câmpul sI este o variabilă de tipul SEMAPHORE, 
destinată realizării excluderii. mutuale "(contorul 
„semajor ului sI se va. imițializa la 1 ) 
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"Mecanismul cutiilor: poştale consistă îi i 
e un tablou de structuri MAILBOX, _mb[ MAX. MBJ: ¥ 
e un set de cinci. funcții care au monopolul. operării 


câmpul. s2 este. o variabilă-dë tipul SEMAPHORE; 
destinată. controlului operatiilor ide citire: din: timpon 
(contorul semaforului s2:se:va inițializa:la 0) 

câmpul. ș3: este: o. variabilă de. tipul SEMAPHORE, 
destinată controlului operatiilor: de scriere: m: tampon 
(contorul semaforului s3 se va inilializa la o valoare 
egală cu dimensiunea tamponuluii) 

câmpul bufI] este o variabilă de tipul DESCRIPTOR, 
reprezentând tamponul propriu-zis 

câmpul ps este: 0; variabilă de tipul: pointer:câtre un 
DESCRIPTOR, destinată utilizării. în procesul de. 


“scriere în tampon... 


câmpul pc este o variabilă de lipul pointer către un 
DESCRIPTOR, destinată. utilizării în pr ocesull de 
citire din tampon š 
câmpul pd este. o variabilă de ï 
către data de comunicat 
câmpul Id este o. var jahil de ti 
higimea datei de comunicat sa 
câmpul ip este o var abilă. de tipul: 
indexul taskului producător. 


l: pointer eenerit 


“asupra structurilor MATE BOX: 


mb_initQ) 
A inițializează “tabloul de cutii poştale: VA 


mb. create). 
/* creează o cutie poştală */ 


nb. destroy) 
A distruge o cutie poştală */ 
(se continuă) 
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(continuare) ooo \ 
o nb y _receivef) o 

F extr age descriptorul unei date din cutia poştală */ 
/* imediat sau, dacă aceasta este vidă, */ + 

| /* după o aşteptare pasivă */ 

A si cu ajutorul lui, accesează data. a pr opriu-zisă 
i _mb send). 


fe depune descriptor ul unei date în cutia poştală T 
- Æ imediat sau, dacă aceasta este plină, */ 


/* după o aşteptare pasivă %/ ; 


elege prin comunicare între taskuri? 
are sunt principalele mecanisme de comunicare? 
. Definiţi noțiunea de conductă. 
9 Ce este, în plan practic, o conductă? 
5) În ce consistă mecanismul conductelor? 
6). Precizaţi rolul funcției p_initQ. 
iz) Descr. “ieți acțiunile funcției P init). 
16). Dafi o implementare C pentru uncjia. p initQ. 
D. Precizați rolul funcției p create). 
o 0). Descr iefi. acțiunile. funcției _ _p_er cate().. 
1 1). Dafi o implementare C pentru funcţia P etel 
12). Precizaţi rolu funcției. _ destroy().. o 
13). Descrieri acțiunile funcției pP dero 
A. Daţi o mplementare C pentru funcția 2- destroy). 
D rolul funcției _p_ receive). 
d! 6. ți acțiunile funcţiei , receive), : 
. Daţi o implementare Cpentru funcția _p_ receive(). 
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- Precizăţi rolul funcției. p- sendQ... 

. Descrieți acțiunile funcţiei. p send). 

Daţi o implementare C pentru funcția :.p. sendQ). 
Cum se asigură comunicarea. prin mecanismul 


. Ce avantaje prezintă mecanismul conductelor? 

; Ce dezavantaje prezintă mecanismul. conductelor? 
. Definiţi noțiunea de cutie poştală. 

. Ge este, în plan practic, o cutie poştală? 

În ce consistă mecanismul cutiilor postale? 

.. Precizati rolul funcției... mb. initQ. 

.. Descrieti acțiunile funcției mb_init(): 

.- Daţi o implementare C pentru funcția mb. înitQ). 
.. Precizăți rolul funcţiei mb creare. 

,. Descrieți acțiunile functiei... mb_creute(). 

. Dați o implementare C pentru functia mb. 
- Precizați rolul functiei mb destroy). ; 
. Descrieţi acțiunile funcției mb destroy. 
„Daţi o $ 


. Precizați rolul funcției. mb. , receiveQ. | 
...Descrieţi acțiunile funcției mab_receive(). i 
„Daţi. 0 


. Precizaţi rolul funcției mb_SsendQ. 

; Descrieți acțiunile funcției mb Ssend()... 

„Daţi o implementare C pentru funcția mb. send); 
: Cum se asigură comunicarea. prin. mecanismul 


. Ce avantaje prezintă mecanismul cutiilor poştale? | 
Ce flezavantaje prezintă mecanismul cutiilor 
poştale? i 


conductelor? 


implementare. 
"mb.destroyQ). 


implementare © pentru. funcția) 


_mb..receive(). 


cutiilor poştale? 


3 
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